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METHOD AND APPARATUS FOR NETWORK CENTRIC 
PROBLEM ANALYSIS AND TOPOLOGY CONSTRUCTION 



Cross-reference to Related A pplication 

This application is a continuation-in-part application of Serial No 
08/493,984, filed June 23, 1995, by James G. McGuire, Richard N. Pelavin, 
Herbert S. Madan, and entitled, System and Method for Evaluating Computer 
Network Performance. 

BACKGROUND OF THE TNVFNTTON 

1. Field of the Invention 

The invention relates in general to computer networks, and more 
particularly, to the design, modification and management of computer 
networks. 

2. Description of the R elated Art 

Computer networks comprise multiple computers that are 
interconnected for communication with each other. A network may include 
only a few computers physically located close together or it may include many 
computers dispersed over a wide area. A network may include subnetworks or 
local area networks (LANs). A network also may include widely separated 
computers interconnected over a wide area network (WAN). Routing devices, 
in essence, are specialized computer networking devices that route or guide 
packets of digitized information throughout a network. Typically, when a host 
computer sends a packet out onto a network, it includes in the packet address 
information that specifies the source of the packet, the sending host, and the 
intended destination of the packet, another host computer connected to the 
network. The sending and receiving hosts ordinarily are interconnected 
through routing devices which use packet address information to route packets 
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2* «- — *om one routing device 
-dmg host , 0 lhc reo , vi „ g ^ Roming devjcK 

complex and critical ro le in .etwrt operations. 

In many environment nenvorks m (<) 
ranges as host computers are added or deleted, for example. UnforZL 
—to are — «*, ,0 failure. ,„ todav , information ^ 
network f ai, U re can nave severe indications t0 croons .a, 
computer networks as a primary M „duit for information. Networ|( 
management is the process of maintaining ft. inte^y of a network „ 
— .unctions such as, observing the state of a network, monitoring 
~ traffic Shooting the network, making changes to ft. ne work 
and ensunng ,ha, the changes have the oesireo effect. Ne^ork management 
has become increasingiy import as ft. si 2 e, diversity and important of 
computer networks have grown. ^ rise in proraineiKe ^ 
underscores the import of high ouahty network management 

Compiex technical challenges are an inherent figure of the n«work 
management Action. For instance, „«work components may be diverse and 
Phys-cally dispersed. Many different communication protocols may be 1 
stmultaneously over the nerwork. Security issues p, ay a role in 

hM,S ™" '° <* « -just a few 

of he numerous factors tha, combine to define the environmen, in wMch 
network management takes plac , w rf ^ ^ ^ 

yp-ca. network manager indude the swift analysis of large volumes of data 
.roub^noot.ng problems in a rimeiy fchion, imp ,e m e mi „ g changes „' 

upgrades without disruption of normai network operations^ 

Numerous network management tools are available to aid in achieving 
network management objectives. For example, there are tools , h a, 

dTtT ,00b ' ha ' m °" i,0r — ' « - (MIB) 

Configuration management tools can produce audi, trails ,ha, i ndiC a t the 



WO 97/49214 PCT/US96/10873 



-3- 

history of changes to routing device configurations. There are network 
management stations that can collect information from network probes and 
present a network manager with data representing the state of the network. 
Simulation tools can predict the performance and behavior of hypothetical 
5 networks. Topology rendering tools can be used to display a topology setting 
the context to identify possible problems on particular network components as 
well as network-wide problems. 

There are particularly difficult technical challenges in the realm of 
network management tools that identify possible network-wide problems and 

10 that render network topologies. For example, it can difficult to determine the 
logical connections between network devices without requiring a live 
operational network. Additionally, the problems associated with providing a 
network centric view of potential problems in a network are significantly 
greater than the problems associated with testing an individual network 

1 5 component for potential problems. Moreover, diagnosing routing table 

problems may involve complex inquiries aimed at identifying routing loops and 
identifying dead end paths, for example. Furthermore, security issues involving 
router access lists can be difficult to diagnose without a relatively 
comprehensive understanding of the operation of the network containing 

20 routers with such access lists, so that, for instance, a route around a blocked 
host can be tracked. 

Thus, there has been a need for improved network management tools 
that can provide network centric analysis of potential problems and that can 
provide diverse views of network topology in order to enhance a network 

25 manager's ability to manage a network. The present invention meets this need. 

BRTEF DESCRIPTION OF TTf F DRAWINGS 

FIG. 1 shows a flow chart of the overall data and process flow of the 
present invention. 
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FIG. ,a shows ,he subprocess of populating , he Stn)ctured 
Objects .ho firs, process occurring ^ FIG , 

FIa!bsho -«^^proce S sofCo„s«ru«ing,heTopolo g vas W o u ld 
log,cal,y f„„ow .he process described i„ FIG. ,a in .he use of the 
5 user "■nine use ottne invention by a 

FIG '"^thesubprocessofCrea.ing.heViewObiecL, , 
•ha. „ ou ,d «ypica„y fo„ow .he process shown in Fig lb ' 

FIG. ,d shows .he subprocess of applying n o„. rou .i ng table checks 

,o zzr ionofthei ~-'~-p~ Figl :r 

(such aT ' 5 ^ SUbPr ° CeSS ° f ImPOrtin8 Au6B "y 

HG 10 Th? I WhiCH " " '° «~» — -s 

(FIG 10 The user selects which of these procedures to use 

ahemauve process .o the procure shown as FIG. ie as described above 

hecks wh.ch ,s the procedure executed following either Fig ,c or F,g ,L 

descnbed above. s 

FIG.lh shows, he subprocess of .he user making changes tol heSRO 
9 ve„ rendered ,ogical .opdogies from FIG. ,b, rendered abs.1 J o ^ 
fora FIG ,c, and i„.egn,y checks from FIGs >d and !f 

FIG H shows, he subprocess of importing modified SROs back into .he 

configurauon as ca P .ured by ,he se, of SROs curren„ y m ,„e da^base 

FIG. a block diagram ofa network comprising rou.ers(Ro> 

and a workmen ,ha, can access the network, and, on which the prod 
FIG'S la-li can run. Processes ,n 
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FIG. 2 shows the object data structure of the "Structured Router Object 
(SRO) a principle data structures of the invention. A set of SROs serve as the 
primary input for all subsequent analysis. 

FIG. 3 shows the object data structure of the "Single Protocol 
5 Topology" object, a principle data structures of the invention that is populated 
in the process shown as Fig lb. It will serve as input to numerous processes as 
shown in FIG. 1 . 

FIG. 4 is a flowchart of the process that creates a Single Protocol 
Topology (SPT) object data structure for a given protocol P given the set of 
10 SROs (FIG. 3) as input. 

FIG. 5 is an annotated topology drawing of a hypothetical network. It 
is referenced by subsequent figures. 

FIG. 6a & b are sample router configuration files for routers in FIG. 5. 
FIG. 7a shows the populated SRO associated with the router 
15 configuration file shown in FIG. 6a, Router 1 (Rl) in FIG. 5. 

FIG. 7b shows the populated SRO associated with the router 
configuration file shown in FIG. 6b, Router 2 (R2) in FIG. 5 

FIG. 8 is a step-by-step walk through of a Single Protocol Topology 
(SPT) object data structure build routine that is shown in FIG.4. 
20 FIG ' S 8 a through 8j illustrate the values of the SPT for Protocol = IP 

following the execution of steps in FIG. 4 as indicated by annotations on FIG 
5. 

FIG. 8a shows the SPT following Step 1, initialized to its EMPTY 

state 

15 FIG. 8b shows the population of the SPT following FIG. 4, Step 5, with 

the first connection (a subnet) added to the object. 

FIG. 8c shows the population of the SPT following FIG. 4, Step 4 with 
a Pointer added to the first Port Address 
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no < z, r t t popuia,ion ^ spt ^ P- <* 

4> S,eP 5 ' ^ "» « ~»" 'o «•» object data sttucture 
FIO. 8e shows the SPT after the second pass of FIG 4 Steo 5 a H rf ' 
the -ex, pointer ,o the SPT object da* stn.cu.re 

po i „.e r ™ne 8 rT thelOOPin8,hrOUghFrG * ^ 
pointer to the second connection. 

and ,a t^ " ^ ,hr ° Ugh F ' G * *"* 5 «*■ «* *W 

and last connection to the SPT object data structure 

,„ W ^ ^ Sh ° WS .' he ^ ^ F '° <• S «P 1 a pointer 

•o SPT tha, po,nts to the las, port address of the hypothetic* network 

configuration. 

FIG 8i shows the competed SPT obje« following FIG, 4, Step 7 

FIG 4 f W0U ' d be * «» <*»» -»« - 

fiu. 4 tor the case where Protocol = IPX 

^ spt f ! g , 9 Tit aaa *° oeaK flowchan in m «• ^ ~ 

SPT s, to check for the integnty violation of duplicate addresses 

subnet ^ 10 " a flOWCha " '° "* inte8ri,y ***» °f overlapping 

subnet masks given an SPT as input. 

FIG. , 1 is a topology drawing of a hypothetical network shown with a 
Campus View. It supports discussion of the "Create Views" process shown as 

FIG. 12 shows the object data structure of a Campus View Object 
corresponding to the topology shown in FIG. 1 1 

FIG. 13 is a flowchart of the process that forms a Campus View Object 
given an SPT and SROs as input. *w object, 

FIG. 14 is a topology drawing of the same network shown in FIG 1 , 
~ 8 4 ; n ° SPF ^ " " ~ C ° nfi8Urati0n — * ' View 
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FIG. 15 is the OSPF View Object data structure corresponding to the 
topology shown in FIG. 14. 

FIG's 16a & b shows the SRO object data structures for the routers 
shown in FIG. 14. 

5 FIG. 17 shows the SPT object data structure for the network shown ii 

FIG. 14. 

FIG. 18 is a flowchart of the process that forms an OSPF View object 
data structure given an SPT and set of SROs as input. 

FIG. 19 is a flowchart expanding on the "AreaSet" concept introduced 
10 in FIG. 18 

FIG. 20 is a flowchart expanding on the "How Many Areas Does 
Router Have" question from FIG. 18 

FIG. 21 shows the object data structure of the Multiple Protocol 
Topology (MPT) object, a principle data structure of the invention that is 
1 5 populated during execution of the process shown in FIG. 1 b. 

FIG. 22 is a flowchart of the process that populates the MPT object 
data structure taking a set of SPTs (for the different protocols) as input. 

FIG 23 is a flowchart expanding on the process of Step 4 7' in FIG. 
22,"matching connections with Multiprotocol Connection (MpC) objects", 
20 FIG>S 24a through 24i comprise a step-by-step walk-through of the 

Multi-Protocol Topology (MPT) object data structure build routine. It refers 
to the topology shown in FIG. 5 

FIG's 24a through 24i illustrate the values in the MPT object following 
the Step(s) in FIG. 22 each of which is labeled with a number inside a circle. 
- 5 FIG. 24a shows the MPT object initialized to EMPTY. 

FIG. 24b Shows the addition of the first MpC for protocol = IP following 
FIG. 22, Step 3. 

FIG. 24c Shows the effect of the loop through FIG. 22, Steps 3, 4, & 5 
adding another MpC and pointers (again for Protocol = IP) to the object 
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15 



FIG. 24d shows the effect of the l00p „ QW 
pointers for Protocol = IP. 

no. ^ C ° m| " e,ed f ° r Pro,oco1 " * 25 «*» 

FIG. 24f shows ,he addition of ,he firs, IPX element of the example 
following execution of FIG. 22, Step 8. 

FIG. 24g shows the addition of the second IPX element to the MPT 
object again looping through FIG. 22, Step 8. 

FIG. 24h shows the addition of the last IPX element to the MPT as 
.0..0WS the last pass through FIG. 22, Step 8 

of FIG. T ^ " ° KUr " «*» 

PIG. 25 shows the Object data structures of the SRO & MPT to 
demonstrate the linkages that to ,er-re,a,e them as they would occur fo.lowing 
execution of the process shown in FIG. lb. 

FIG. 26 shows an annotated network diagram and instantiated SPT 
object data structures that demonstrate a violation of the integrity check tha, 
rinds mismatched protocols during the building of the MPT 

FIG. 27 shows a flowchart for the process for resoiyng IP-unnumbered 
connections using connections of another protoco,, this process occurs during 
tne topology construction phase (FIG. lb). 

FIG. 28 is a topology drawing of a hypothetical network that wi„ be 
referenced a ,ong with subsequent figures to show how information missing 

FIG. 29a - 29d show hypothetical Router Configuration Files for 
routers (R3 through R6) shown in FIG 28. 

FIG. 30a shows the SRO object for R3 in FIG. 28. 
FIG. 30b shows the SRO object for R4 in FIG. 28. 



20 
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FIG. 30c shows the SRO object for R5 in FIG. 28. 

FIG. 30d shows the SRO object for R6 in FIG. 28. 

FIG. 30e shows examples of the IP and IPX SPT object data structures 
as they would be populated following the execution of the SPT build process in 
5 FIG 4 for IP and IPX. 

FIG 3 Of shows an example of the MPT object data structure as it 
would be populated following the execution of the process in FIG. 22 taking 
the SPTs in HG 30c as input, and refined with the additional process shown 
as FIG 27 that fills-in information missing due to the use of IP-unnumbered. 
10 FIG 3 1 a repetition of FIG. 4 (a flowchart of the process that 

populates the SPT object data structure) annotated for integration with a 
flowchart for handling the Frame Relay WAN complication to the SPT build 
process 

FIG 32 is a flowchart that shows the set of extensions to FIG 3 1 
1 5 required to handle the Frame Relay WAN complication to the SPT build 
process (FIG 4) 

FIG 33 is the merged result of FIG's 31 & 32 and shows the complete 
set of logic applied by the invention to accurately populate the SPT despite the 
complications introduced when the process encounters the presence of Frame 
20 Relay multi-point WAN. 

FIG 34 is a topology drawing of a hypothetical network. It is 
referenced by subsequent figures in support of the illustrations related to the 
Multipoint WAN complication discussion. 

FIG 35 shows a SPT object as would be prepared by a naive algorithm 
25 incorrectly creating pointers for a Frame Relay WAN (FIG. 4) without the 
enhancements shown as FIG. 32. 

FIG 36 shows an accurate SPT object for FIG. 4 as computed by the 
SPT build algorithm that takes into account Multipoint WAN complication as 
shown in FIG. 33. 
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HG. 37 shows the SRO object for router Ri in FIG 34 fn. ■ 
Frame Map objects. f ° CUS,ng on the 

FIG. 38a - d shows the router configuration files for each router 
•liustrated in FIG. 34 (topology to demonstrate the Frame Rela • 
WAN example) the Fra ™ Relay multipoint 

in FIG 3; h 39 ? r ° U8h Sh ° WS ^ SteP " by - SteP ~« of the flowchart 
n FIG 33 by bating values of variables and instantiations of the SPT 1 
each step of the flowchart is executed This is part of th 
FIG. lb. prOCess occu «-ring in 

FIG. 40 is a flowchart showing the process for determining bandwidth 
and delay mismatches between adjacent routers. This is an integrity checL 
occurs during the phase indicated as FIG. Id. 

FIG. 41 is a flowchart showing the process for determining the 
existence of unresolved static routes as coded in router configurations this is 
integrity chec k that occurs during 

FIG. 43 is a flowchart of the process for determining access list 
subsumption probiems, this is an integrity ch eck applied during the phase 
shown as FIG. id. P 

KG 44 is a flowchart showing the process for ^ 

— a SPT a„ d SROs as input, it occurs duri „ g ^ rf 

tables from the network as shown in FIG. le. 

FIG * *" m0difiCa,i0n ^ "> "»w„ in 

ha " d,e ,ot,ps enc ™ — ^ — 

that ff r mP ™ 0nm0dMCa,i0n, ° ,ha ' Sh0 »» i "«G 44a 

■ha, ^.entiy handles ioops encountered whiie creating rou,,„ g tables 

FIG 45 shows the object data secure of the Routing TaWe 0 

Th, ob.ec. is popped d uri „ 6 either of the processes shown as nd Z f 
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lt becomes input to the process shown in FIG. lg which evaluates integrity 
checks that use routing tables as input. 

FIG. 47 is a topology drawing of a hypothetical network and a 
definition of the Current Path Set (CPS) concept. It is used to provide 
5 background to enhance the readers understanding of the concepts explained in 
FIG's 48 through 56. 

FIG. 48a, 48b & 48c comprise a flowchart that describes the process 
of finding paths from a Source Address to Destination Address, which is used 
as a subroutine as part of the phase shown as FIG. lg. 
10 FIG. 50 is a flowchart of the subprocess of matching routing table 

elements per FIG. 48b Step 12. 

FIG. 51 is a hypothetical network topology map annotated with port 
designations and subnet addresses to be referenced in subsequent FIG's 52 
through 56. 

15 FIG. 52 shows a SPT object data structure corresponding to the 

topology shown in FIG. 5 1 

FIG. 53 shows part of a routing table object data structure for router 
Rl in FIG. 51. 

FIG. 54 shows part of a routing table object data structure for router 
20 R2 in FIG. 51. 

FIG. 55 shows part of a routing table object data structure for router 
R3 in FIG. 51. 

FIG. 55a shows part of a routing table object data structure for router 
R4 in FIG. 51. 

25 FIG. 56a - f shows a step-by-step walk-through of the flowchart in FIG. 

48a,b,&c (a flowchart for finding Paths between Source Address and 
Destination Address) using the topology illustrated in FIG. 51 as the example's 
input. 



S DOC ID: <WO 974921 4A1_I_> 



WO 97/49214 



St 

PCT/US96/10873 



10 



15 



20 



25 



-12- 

dement is blocked by an access Ii« tu , ■ ■ ■ swnea "*°' 
process shown as FIG. lg ' ' 08,C " '"^ **« *• 

FIG 4.^ 1" ^ tha ' *°"**' ra0difati - » *• flowed in 

FIG flowchart of a modified the invenlion app|ie „ 

process snow„ ,„ no 48b to hand , e pa(hs iQ a 

sno F '^ 6: " ' fl0WCha " ° f 3 PrOCCSS Which " * ™™ <° «■» Proems 
-«.-c.oba„,ca P a thstaningftomar _ JnsiMd ^ h 7 st 

FIG 67 ,s a topoiogy rendering showjng RSRB connections 

^ P™<~ dtscussion and subsequent flgure , ,„ ^ 

,„, „ua,,.y of connectivity gi ve„ instances of ,eve, 2 connect (i . 

bnOm - or specif Remote Source Ro„,e Brid ghg (RSRB)). ' 
HG 68a is a sample router conf lg ura,i„„ file for Router Rl in FIG 67 
no 6 b .s a sample router configuration f„e for Rou, er R6 in m „ 

Kouters Rl and R6 havmg configs in FIGs 68a and 68b 

FIG 70 shows a flowchart that computes the "RSRB/DLSw rem ote 

— ^^C::hi::::: ta, Tr the " BGpremo,en ^ 

egnty check. Th,s <s part of the phase shown as FIG. lg. 
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FIG. 72 shows a flowchart that computes the "User supplied 
connectivity requirements" integrity check. This is part of the phase shown as 
FIG. lg. 

FIG. 73 shows a flowchart that computes the "Routing Loops" integrity 
check. This is apart of the phase shown in FIG. lg. 

DETAILED DESC RIPTION OF THE PREF ERRED fmr M fnt 

The present invention comprises a novel method and apparatus for 
network management. The following description is presented to enable any 
person skilled in the art to make and use the invention. Descriptions of specific 
applications are provided only as examples. Various modifications to the 
preferred embodiment will be readily apparent to those skilled in the art, and 
the general principles defined herein may be applied to other embodiments and 
applications without departing from the spirit and scope of the invention. 
Thus, the present invention is not intended to be limited to the embodiment 
shown, but is to be accorded the widest scope consistent with the principles 
and features disclosed herein. 

The purpose of the present invention is "to assist network managers, 
administrators and/or planners manage routed networks for which they are 
responsible "Routed Network" herein means a set of logically connected 
devices, each of which can operate as a switching device at level 3 in the OSI 
model. A presently preferred embodiment of the invention is architected to 
operate in connection with any of the following environments: a live network 
to manage; proposed network configuration information existing for a planned 
network to be analyzed; a live network along with configuration information 
for a set of planned changes; or, multiple live networks to be merged. 

A high level view of Figure 1 shows an overall process, in accordance 
with a preferred embodiment of the invention, for obtaining network 
information from a variety of sources, putting this information into the 
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da* base, Bering dffleren, views of I(le 
vanous mtegritv checks , using m infom]at . on (o dec . de J 

— « .o be addressed, raaking correct™ tf ^ „ 

back in the data base for reiterative analysis In «,m *w 

analysis, in sum, this process assists th*» 
«~ to: capture nMworlt configuralio „ infonnationi 

■"^~, configllration , evaluatethatjn PJJ- 

prospecve changes, and, either down,oad the conflguration ^ ^ ^ 

' r -a^ b ase d „„ theori8Wco „ fi ^ io r 
— . ,e prospecve changes appiied. A key facer is that lne inventlo „ 
P-acUve va.ida.ion of a pianned network or ^ ,„ _ ^ 

~ manager, therefore> „. ^ ^ ^ ■ 

^■^~*^««^.»*-.- 

witnout the invention. 

Throughout the lowing discussion i, rt turned that line . 

,s we,, within the abilil , s oforK skiUe<J jn m so . ^ 
Each sub-figure (,a - ,i) in Figure , relates , Q a 
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The process represented in Figure la parses the input data from, for example, 
configuration file, the manager output, or MIB data capturing a router's 
configuration, as described above, and fills-in default information as necessary 
to populate object data structure referred to herein as the Structured Router 
5 Object (SRO). 

Figure lb represents a process of forming a "topology" from the SROs. 
In the presently preferred embodiment of the invention, there are several types 
of consitutent components of the topology. One type of component comprises 
is a set of objects called SPTs, for "Single Protocol Topology". An SPT is 

10 produced for each protocol running on a network, such as IP, IPX and 

Appletalk™ Running multiple protocols in a network has become a common 
practice in networking. Each SPT indicates for a given protocol which routing 
device ports are running the given protocol and which ports are logically 
connected over the protocol. Another type of component comprising the 

1 5 topology is implemented as an object referred to herein as an MPT, which 

stands for "Multiple Protocol Topology". In the present embodiment, there is 
one MPT per network. The MPT includes information that indicates how the 
SPTs relate to each other. For example, if a network routes both IP and IPX, 
both an IP SPT and an IPX SPT will be created, and they will be cross- 

20 referenced to each other to form an MPT. 

The novel MPT can be used, in conjunction with novel processes in 
accordance with the invention, to determine whether network protocols have 
compatible addressing. 

Processes in accordance with the invention can determine when two 

25 topologies have incompatible addressing and can identify the source of the 
conflict, such as the parts and protocols involved in the conflict. More 
particularly, during the process represented by Figure lb, logical topologies are 
produced for the different protocols that run on a live or planned network. 
These topologies are called SPTs and are produced from the SROs. Once 
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SPTs have been conned for , ne various 

w,.h each other to form . stnicture ^ ^ ^ J 

conflicts be,wee„ prcoco, , the ^ 

SPTs and ,he MPT provide vahtabie diagnostic information _ ^ 
m identifying network problems. 

^P-cesses represented by F igurelbproduce , eve| 3 
•opolog.es. A ,eve, 3 iogica, .opoiogy „ defined ^ tne os , ^ 

represents a process which provides more abstract or -higher iever vie! or 
£ esentat of a „ ^ rf ^ ^ . 

OSPF and BOP view, These more abs»ac, views can be use*,, ,o a network 
«-*r or designer who wishes ,„ observe oniy cenain abstracts or 2 
of a network Modem networks are ex,eme ly comp lex creations. Higher 
eve-We abstract views enabie the persons response for mamtainjng 
destgnmg or modifying networks to better vtsuaiize the network they are' 
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network typically invoived a user evaluating routers one by one to determme 
whether there are probiems with individua, router, conflguranon, A ro! 

rrrr a rou,er is ,o process ^ m * - 

packets, and how ,, generates, receives, and processes messages that are sen, 
between ttseif and o,her rou,ers ,o cons,™ rou,i„g ,ab,e, The objec, Hi 
produced ,„ accordance wi,h ,he processes of Figure ,b enab,es a more 
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important feature of the process represented by Figure Id is the application of 
numerous novel integrity checks which can identify problems in not just 
individual routers, but across routers spanning the whole network. "Integrity 
Check" as used herein means the result from a procedure that determines 
5 whether there is a critical or potential problem in the network configuration. 

The differences and relationship between the views produced according 
to the processes of Figure lc and the integrity checks represented by Figure Id 
are as follows. Thus, in the current embodiment, high level/abstract views may 
be used for rendering images of various protocol topologies; while integrity 

10 checks ordinarily represent information in a more textural form. A user can 
employ both views and integrity checks to diagnose potential problems with a 
network. More to the point, views set a graphic or visual context for 
interpreting textual reports of integrity check violations. For example, an 
integrity check violation may identify a network component or components 

1 5 such as a router or a subnet; while the view permits a user to visualize where 
the component or components resides in the network and its relation to other 
network components. 

Referring now to Figure lg, there are multiple types of integrity checks 
that can be performed given routing tables as input. A routing table is a table 

20 with rows (elements) indexed by level 3 destination addresses and/or level 3 

"summary addresses", which refer to ranges of addresses; if a router receives a 
packet that is not filtered on the incoming port, (and the packet's destination is 
not the router itself), it will look for a routing table element that matches the 
packet's destination. If no match is found, the packet is dropped. If there are a 

25 number of matches, then the element with the narrowest range (i.e., most 

specific address range) is used. The matching element indicates what port to 
send the packet out of and either a next hop router or the fact that the port is 
connected to the local area network (LAN) where the destination resides. The 
packet is sent out this output port unless there is an output port filter that 



NSDOCID: <WO 974921 4A1J > 



WO 97/49214 



PCT/US96/10873 



-18- 



blocks trar^on Routjng taHes are 

exchange infection about dKtinaijons - » ~ 

13-115. Pren U ce Han .„c, network J" 

^ be . roule through fc ^ ° <° »■ -ever, 

•able* are used ,o switch .he packets "hop-by-nop- J" h t r ° Ut "' 8 

;:: r - - — - -i CCr;;;;;r 

— uai.ce w,u, the invcation. Another examole „f a • " 

check ic t»,o* *u example of a routing table 

P-e,s destined for ^ D and transmit ^ ; ^ 

- s these pack«s ,„ Router 3 which sends ^ ^ « ^« 

There are a nuntber of approaches to gathering the routing tabie 
■nfomw, 0 „ for use in the process of Figure I e On,, u 
Raure lfi,,„ , , / "'■"■Sure 1g One approach represented by 
■gu ,f , 0 almine , he routin8 tab)es (hrough ^ y 

topology (SRO/SPTs/MPT) as inm.t Tk- , =™g«ie 

uung tables, then, ln accordance with a process 
represented bv Fieurf i- a- Process 
y ri 8 ur e le, the user can poll live routPrc ;„ * 

illustrated in general font, in F i 8ure lf 8 ^ 17 

Figure lh is a process largely guided by the user „i,„ k 

accordine to oth*»r automatically computed 

ng other process represent i„ Figure Given this Nation, the 



-19- 

user can observe the problems in his or her network, and consequently may 
make modifications to the object model (i.e., the topology comprising 
SRO/SPTs/MPT). Once the user makes changes he or she has a number of 
alternatives. One alternative, represented by Figure li, is to make the changes 
and download those changes directly into a live router network by providing 
the information on the SROs to live routers in a live network. Another 
alternative, represented by the feedback path that includes the "what if 
Analysis" comment, is to modify the SROs in the object model and reiterate 
through the process steps described above in order to analyze and trouble- 
shoot the proposed network changes represented in the updated SROs 

A significant advantage of the invention is that the information in the 
object model (SROs/SPTs/MPT) can be both used for analysis (creating views 
and running integrity checks for example) and for actual download to a live 
network. This advantage is achieved in the preferred embodiment by storing 
router configuration information in executable form in the SROs. The term 
"executable" as used herein means a state of representation of router 
configuration that contains sufficient detail so that it can be translated into a 
form that a router can directly execute. 

Thus, Figure 1 shows the overall process, in accordance with a present 
embodiment of the invention, of obtaining information from a network, putting 
it into a data base, applying different types of integrity checks, rendering 
different views, using this information to determine if there are problems, 
making corrections, if there are problems, and either downloading these 
corrections to the network or putting these corrections back in an object mode 
data base for further analysis. Consequently, a user can capture an existing 
(live or modeled) network configuration, analyze it, find problems, evaluate the 
problems, proactively validate changes before downloading the changes back 
into the network. An important factor here is that such proactive validation 
permits making validated changes to a routed network without impacting 
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select the appropriate router configuration commands to correct the indicated 
problems, reload these changes to each affected router in the network and then 
run Make's "discovery" process to generate a data model for the analytical 
process to be run again. As used herein, "discovery" means a live process 
5 performed on an actual network that identifies elements and their connections 
in the actual network, which relies on the elements and their ports being 
operational during the process. Contrast the difficulty and potential 
inexactitude (room for human errors) of that process against the ability of the 
present embodiment of the invention to assist the user in identifying potential 
10 problems via views and integrity checks, automatically generate executable 
configuration files and before implementing those changes to a live network, 
check the proposed changes before then automatically loading the fully 
executable files to the live network for both Cisco Systems and Bay Networks 
products. 

1 5 Figure 2 depicts the Structured Router Object which, in accordance 

with a presently preferred embodiment of the invention, we will refer to herein 
as the SRO. The SRO is a data structure encoding the contents of a single 
router's configuration that are relevant to a given network analysis at hand. 
We refer to this data structure as "structured" to convey that it is composed of 

20 interrelated attributes and to distinguish it from such constructs as a text file 
containing a router's configuration which is amorphous rather than structured. 

Figure 2 illustrates a sufficient subset of the components constituting an 
SRO to enable one skilled in the art to practice the invention. In an actual real- 
life SRO there are many more components. A SRO, as well as other structured 

25 objects referred to in this disclosure, can be described in the hierarchical fashion 
by starting with top level attributes and then explaining and illustrating how 
these attributes are further decomposed into lower level attributes. In the 
disclosure that follows, structured objects will be presented in two different 
ways: i) in attribute form, which is a description of an object's interrelated 
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The next four attributes shown in Figure 2 (labeled as (3)) are attributes related 
to access lists. Access lists are used to filter traffic coming in and out of the 
router. Typically access lists are used for security purposes and routing 
purposes Access lists are used to block or permit packets with either specific 
5 addresses or ranges of addresses, to be received or transmitted by a router. 

The first access list attribute illustrated in Figure 2, (AccLstIP), stands for input 
access list, IP This access list item is used to filter input IP packets. The 
attntxjtc Out AccLat refers to filtering output IP traffic. Similarly, the attributes 
AccLstlPX and OutAccLatlPX refer to filtering input and output IPX packets. 

10 It should be appreciated that access information for other protocols, such as 
AppleTalk. has been omitted from Figure 2 for simplification. 

The last attribute under the port object is Port_addr. Each port has one 
or more addresses assigned to it. The Port_addr object has an attribute called 
"protocol" which refers to a particular address' level 3 protocol, such as IP, 

1 5 IPX, and. AppleTalk. The address attribute gives the exact address. Port 
Addresses serve as building blocks for forming the topology information. 

The SRO structure accommodates multiple port address per port as any 
given port on a router may be running multiple protocols. For instance, 
consider a port configured for both IP and IPX. Typically such case, one 

20 would have both an IP and IPX address for this port. Another reason for 

having multiple port addresses is that routers produced by Cisco Systems, for 
example, employ a concept called primary and secondary IP addresses where 
the user could address the same physical port with multiple IP addresses. 

Before discussing the next high level attribute of the SRO, Protocols, 

25 we consider the difference between this high level attribute and the subobject of 
the Port Object similarly named Protocol. The latter refers to the protocol(s) 
"running" on the particular port. These port-related protocols define the type 
of the packets of data that come in and out of the router's ports (i.e., IP, IPX, 
AppleTalk, DECnct, etc) By contrast, the high-level attribute Protocols refers 
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there is a number referencing an access list. Each access list object in the list 
Access Lists contains a full description of the access list and a number (see 
reference numberal 7) used for reference elsewhere (such as at InAcclstIP). 
The Elements attribute in an access list refers to a list of patterns which 
5 describe what addresses to permit and deny. 

Still referring to Figure 2, we see an example of the next high level 
attribute called SRB JBridge_Groups. SRB stands for "Source Route 
Bridging," which is a mechanism for transporting traffic typically associated 
with Level 2 in the OSI model. There is also a variant of SRB bridging 

10 implemented in routed networks where SRB traffic can be encapsulated over 
an IP backbone. SRB_Bridge_Group and RSRB-Peer objects are specified in 
the SRO. Each bridge group has a group number associated with it and a list 
of peers. Briefly, a peer is an object with an attribute specifying encapsulation 
type, which indicates what encapsulation method is being used to transport 

15 SRB frames. One example is TCP encapsulated; another example, which Cisco 
Systems provides, is FST encapsulation. The other attribute of a Peer object 
may indicate the address of another router in the network where encapsulated 
SRB data should or potentially should be sent. 

Thus, to summarize Figure 2, the information in the SRO captures a 

20 router's configuration. The information put into an SRO could be gleaned 

from a MIB or from a router configuration file, or from information regarding a 
planned or hypothetical network. A SRO structure, in accordance with the 
present embodiment of the invention, can serve as a neutral repository for 
configuration information from virtually any router vendor whether they use 

25 binaries or configuration files. 

Figure 3 represents a Single Protocol Topology (SPT) object in 
attribute form, in accordance with a presently preferred embodiment of the 
invention. An SPT is formed for each of multiple Level 3 protocols (e.g. FP, 
IPX, AppleTalk). The SPT for a given protocol "P" represents a logical view 
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this configuration feature as assigning secondary IP addresses (as well the 
mandatory primary IP address) to a router port. Although the actual 
implementation of the invention makes a distinction between primary and 
secondary addresses, this disclosure does not make this distinction, and simply 
states that a port has a set of IP addresses. Thus, in general a port may have 
one or more addresses for any protocol. Now suppose that two ports, SI and 
S2, respectively, on routers Rl and R2, are physically connected through a 
serial link, and both these ports have two IP addresses assigned. Furthermore, 
assume that the first IP address on Si, whose pointer would be (R1,S1,IP1) 
belongs to the same subnet as the first IP address on S2, whose pointer would 
be (R2,S2,IP1) also suppose that the second IP address on SI, (R1,S1,IP2), 
belongs to the same subnet as the second IP address on S2, that is (R2,S2,IP2) 
In this case, although there is only one physical medium connecting the two 
ports, that is a single serial link, the IP SPT containing routers Rl and R2 will 
have two (logical) connections for this one serial link. 

Thus, to summarize Figure 3, a Single Protocol Topology, SPT, is a 
data structure that can be produced for each Level 3 protocol such as IP, IPX, 
and AppleTalk. A SPT for some protocol P is a logical view of the topology 
from the perspective of protocol P. This data structure indicates which router 
ports are configured to run protocol P and how each of these ports are logically 
interconnected with respect to the protocol. Although the network under 
analysis may contain Level 2 devices, such as bridges and switches, but at a 
Level 3 view, these devices are "invisible" meaning, for example, if there is a 
switch between two router ports in the Level 3 view, the ports are still viewed 
as being directly connected. A SPT differs from an SRO in that, while a single 
SRO captures the configuration of a single router, a single SPT captures the 
logical interconnections of a set of routers. 

The following discussion describes an earlier tool by Make Systems, 
and explains some significant differences in the process that tool employs to 
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contrast, an SPT formation process in accordance with the present invention, 
handles all protocols using the same algorithm. 

Figure 4 is a generic procedure for forming a SPT for some protocol P 
from the set of SROs corresponding to the routers spanning the network. 
5 When we say "generic" we mean that this procedure, aside from a function 
called the SUBNET function, referenced in by numeral (3), is the same 
regardless to whether P refers to IP, IPX, AppleTalk or DECnet, etc. Figure 4 
provides a flowchart of the SPT build process of the presently preferred 
embodiment of the invention. At Step (1) the Output SPT p is initialized (set to 
1 0 empty) to indicate that initially there are no connections in the SPT for 
protocol P. 

Step 2 initializes a variable PA to the first port address of protocol P in 
the list of routers. Given the set of SROs that contain router information for the 
network under consideration, the invention arbitrarily orders this set in an 

15 ordered list. 

Step 3 asks whether the subnet function (which will be different from 
protocol to protocol) associated with port address PA already in the SPT p " 
Initially, since SPT p is empty, the answer will be "no," and the algorithm moves 
to step (5). At Step (5) a new Connection object with subnet attribute set to 

20 SUBNET p (PA) is added to the SPT p . A "Connection" object represents a 

particular connection between a set of router ports. If the answer was "yes" at 
Step (3), (in other words, SUBNET p (PA) is already in the SPT), then the 
invention would skip directly to Step (4). Next, at step (4) a pointer is added 
under the subnet to that port address PA. Next, after step (4), go to Step (7) 

25 and ask if the last port address has been reached. If so, the process is finished 
because all the port addresses have been processed. If the answer is "no" then 
Step (6) is reached where PA is assigned the next port address and the process 
repeats itself by looping to Step (3). 



vJSDOCID: <WO 9749214A1J_> 



WO 97/49214 



PCT/US96/10873 



-30- 



The define for the subnet functions are gi ven in box „„ 
bottom o Figure 4. For rp, lhe inpu , w , he ^ 

A an, 32 b,t mast M1 conflgura , „„ . ^ ^ ^ - 

5 *T b r m : where *• i$ fom,ed * - -* mi 

examples m this patent we us« th» „ "mine 

th» , - „ address-par, of the subnet as shorthand for 

•he enure subnet For exampie ,0,0 0 0 is used for [10,0.0.0 255 255 0 0, „ 
« s sh^hand cannot he used, bu, if ,h e masks used as either 255.0 0 
255.25^0.0 or 255.255.255.0 and the zero subnet is no, a„owed, one can infer 
10 the mask from the address-part. 

the IPX™ 6 T *" ,C,i0nS ^ ** APP ' eTalk « FOT «■«" 

1 ..TT " umber 35 input - subnet returas *■ - w - 

subnet. « for AppfcTaUc, ^ low ,„„ ^ ^ ^ J 
■ange, the subnet function simply r eu,ms this range as output 

^ in the s I", " SUra,Mry- ^ PrOCCdUre i,emeS "" 0U8h - 

- .be set of routers and adds a pointer to each port address into the SPT 

~ grouping i, W i th other pon addresses Monf . ng ^ ^ 
bas,c SPT formation process is modified in practice to hand.e complicating 

(WAN s), bke Frame Relay, which is described later in this disclosure 

that h T e5 t ' " Se " eraIi2ed ^ ^ ° f 3 Simple —P* ««* 
bat shall he referenced in a numberof suoseouen, figures. 

2Zr° TT R ' ^ T <™~ directly connected 
.brough a set,, ,„ this and subseuuen, figures, ^ are designated by an 
• abbrev.at.on for metha type and a numher such as "EA." on router R] w h*h 
means Ethernet 0 On R I str, „„„ u . v . . 

see .ha. i, , ' S '" ' he 1Cft ° f ,he di W we 

~ that .connects ,o a symbol, labeled (,), which refers to an etheme, Also 

assocated wth the ..heme, are two numeric designators - "10 30 0 0" which 
-berPsubnetnumberoftHisethemetins.ndardn.octetnotatioran:: 
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which is the IPX network number associated with the same ethernet. In other 
words, there is one ethernet designated at (1), but it has an IPX network 
number 9C and IP subnet number 10.30.0.0. Traversing the drawing from left 
to right, we see port SO (Serial 0) on Rl which is connected to a line that 
5 designates a serial link with HDLC encapsulation. Following to the other side 
of the link, we see the port SO on router R2. We can say that Router Rl, 
through a serial link, is connected from port SO to Router 2 through Router 2's 
port SO. For serial links, like ethernets or other LANs, we can identify both an 
IP subnet, which in this case is 10. 10.0.0 and an IPX network number, which is 

10 7 A. Router R2 includes port Ea. (for Ethernet 0) which is labeled (2). This 

portEO at (2) has IP subnet number 10.20.0.0 and IPX network numbered 98. 
In this example, we show a network where both IP and IPX are running on all 
interfaces. It should be appreciated that there may be networks in which 
different protocols run on different interfaces. For example, an interface might 

15 be running just one protocol or running none at all. Also, an interface could be 
running other protocols, such as AppleTalk and DecNet. 

Figure 6 A shows the text configuration file for Router Rl and 
Figure 6B shows a text configuration file for Router R2. See, Cisco Systems, 
Inc. "Configuration File Load Commands", Router Products Command 

20 Summary, pp. 6-584, Cisco Systems, Inc., 1992-1995. Figure 7 A illustrates 
the SRO that corresponds to Router Rl's text file, and Figure 7B shows the 
SRO that corresponds the text configuration file shown in Figure 6B. 

Briefly stated, a text configuration file is put into SRO form using 
standard parsing techniques. In addition, certain default values also are entered 

25 into the SRO. There is default information that is implicit in the configuration 
file. By omission, attributes still have values. As an example, refer to 
Figure 6 A and note where we designate (1), a bandwidth statement for Serial 0 
Router Rl . Refer now to Figure 7 A; at the point that is marked (1 ) is an 
associated bandwidth value of "1000". This bandwidth statement was 
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0 



ex P „c,y coded in Figure 6A, and consequent was ^ ^ 
putrnto-heSROofFi^A. 

labeled (2), which i, interface Ea. for R2. in this case , , nere is no 
Wrt, I0 Figure ?A „ , he po . nt ^ ^ ^ 

bandw,d,h ,s assigned ,he value ,000 The face <ha. ,he ba„dwid.h a, (2) a*i 
•heone.abeledO^ebo.h ,000 is jus. an anifac, B y defau,,, each of ,he 
Afferent me dia , «* as etherne. have bandwidth senings, which are , ne default 
values These are values, for example, ,ha, a Vendor such as Cisco Systems 
makes public in documentation. Aether example of default values is apparent 

_ - ... JN„ -cay hwSmm tor ether of the interfaces is coded in 
F.gure 6A, bu, referring to Figure 7A a. the regions ,abe,ed (3) and <4> delay 
parameters are specified. These were inferred knowing tha, Pon [I ) is an 
etherne, which has a defau,, delay of ,00, and tha, Port [2, is a serial interface 
which has a default delay equal to 2000. 

Figures 8A through 8, show a walkthrough of the flowchart in F.gure 4 
(a deptcuon of .he process for constructing the SPT for a given protocol) For 
■tos walkthrough, the ,„ P u«s are the two SROs given in Figure 7A and 7B ,n 
*. case, we wil, be producing a SPT for pro,oco, IP. In the walkthrough we 
«U be referring to the steps which are numbered in Figure 4 and discussing 
what happens a. each step. The result wil. show the incremental build of the 
output, an IP SPT for the SROs of Figures 7A and 7B. 

In Step (1) the SPT is initialized. Figure 8A shows the SPT a. this 
pornt; protocol is set to IP and there are no connections. 

In Step 2 .he variable PA, which refers to a port address, is assigned the 
firs, port address (referring ,o Figure 7A, .he port address marked (5) in the 
dtagram). No.e <ha< .he por. address assigned has .wo ports 10.30 7 2 - which 
is the address - and 255.255.0.0, which is (he mask. 

Step (3) asks the question whether the subnet associated with PA is in 
the SPT. The subnet for this PA is 10,30.0.0. The convention,, approach to 
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applying the subnet function for the IP protocol follows a simple rule: for each 
of the four octets in the address apply the corresponding mask octet using the 
bit-wise AND operation. For the special case when the mask octets are Os and 
255s, we can use the rule: if there is a 255, it means use the corresponding 
octet - if there is a 0 that means ignore it (i.e. "zero out") the corresponding 
octet. Thus, given PA set to 10.30.7.2 255.255.0.0, we use the first to octets 
and ignore the last two, yielding 10.30.0.0. See, Comer, Douglas E., 
"Implementation of Subnets with Masks", Internetworking with TCP/IP, pp. 
273-274, Prentice Hall Inc., 1991. 

Since the STP at this point is empty the subnet, 10.30.0.0 is not in this 
SPT. Thus, the answer to the question in Figure 4, Step (3) is "no", and the 
process moves to Step (5) where the process adds a connection Conn[l ] with 
subnet 10.30.0.0 to the SPT. Figure 8B shows the state of the SPT after this 
operation (Step 5). 

Step (4) adds a pointer to the current port address (referred to as 
R1,E0,IP1) under the connection that is labeled 10.30.0.0. Figure 8C shows 
the result after this step. 

Step 7 asks whether we reached the last port address. In this case, we 
have not - there is three more to process - so the proceeds to Step (6). 

In Step (6) the variable PA is set to the next IP port address, which is 
the port address labeled (6) in Figure 7A. After Step (6), processing moves 
back to Step (3). 

At Step (3) the process computes the subnet for this new port address; 
- in this case, the subnet is 10. 10.0.0 which is not in the SPT - so the answer to 
Step (3) is "no". 

The process proceeds to Step (5) and adds a new connection, whose 
subnet is 10. 10.0.0, to the SPT that it is building. Figure 8D shows the state of 
the SPT after Step (5). 
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Next, processing proceeds to Steo (4\ u,!,.™ 
. iiep W where a pointer s added to PA 

e ^ being R1 , S0 , ff , . UD<ter the subae , , a , ° ■ 

structure in Figure 8e. 

Ne* M Ste » — we are no, a, ,„e , ast pon ^ 
no . thus process,,* moves ,o S,ep (6), and t he port address is set ,„ ,H 

words, ,he por, address is assigned 10. ,0.4.2 with msk 255 255 „ 0 " 

Processing m oves back ,o Step (3). and compu.es .he subnet f or & 
PO-doVess, which is , „, 0 , 0 , ^ ,„ e _ m step jn th _ s - 

yes , because 10. 10.0 0 matches Conn[2]. 

Processing moves directlv , 0 Step (4)> ^ ^ 

(5). and s ,mp, y adds a poi ot er to the por, address under the matching 
connection (Conn-2,) (i ,„ , hc connection associated with subnet ,0,000) 
Refemng ,„ Figure 8F , ^ „ shown ^ ^ ^ ^ 

The process proceeds to Step (7) PA is not the las, address So 
processing then goes to Step (6, where PA is assigned the address which is 
shown m F,gure 7B at the port address labeled (2) 

with PA p T e r 8 r es "* ,o s,ep (3> and c ° mputes *■ 

-h PA wh-ch ,n ,h.s case is ,0.20.0 0 The answer ,„ Step (3, , s in 
SPT , and thus processing moves to Step (5) and adds fa subnet to the SPT 
resulting m the structure illustrated in Figure 8g. 

Conn Jrt 8 lhe " ^ '° (4> WhCre ' POi " Kr " -*r 
Conn(3] (,e„ the connection aviated wi.h 10 20.0.0) to this pon address 
wh,ch ,s R2,E0,n> 1 as shown in Figure 8H 

nor. Hr° Ce f * mOVB '° (7> ^ Si " Ce ~* ^ ~*d the las, 
Po, address the answer is V s» and .he process is, erminated Figures, 

*Ws ,he resuhing SPT after all ,he processing is com P le,e 

Figure 81 is ,he SPT for protocol D> The data secure of Kgure 8, 
resents ,he fP connect shown in F.g U re 5 „ wi„ be heipfu, to^hl 
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81 corresponds to Figure 5. Referring to the SPT in Figure 81 at the region 
labeled (1), note that there is one subnet (10.30.0.0) that connects to just one 
pointer A pointer is a link into the SRO substructure corresponding to a port 
address The single pointer under Conn[l] (in Fig. 81) links to Router Rl's 
5 port Ea *s only IP address. Conn[l] can be interpreted as capturing that subnet 
10 30 0 0 which has one router point attached to it, namely router Rl's Ea.. 
Since ' L* refers to an ethernet, this connection can be associated with an 
cthcrnct Next, refer to Conn[2] in Figure 81, and note that this is associated 
with subnet 10 10 0 0, which is labeled (3) in Figure 5, the Serial Link. This 
10 serial link connects two ports, represented in the data structure by the two 
pointers associated with Conn[2], Lastly, Conn[3] corresponds to subnet 
10 20 0 0 which is an ethernet with a single router port attached, Router R2*s 
Ea 

Figure 8J shows the SPT that would be produced if the procedure in 
15 Fig 4 were applied to SROs in FIGs. 7a and 7b for protocol IPX. A difference 
between the IPX and IP walkthrough are that, for IPX, PA will be assigned 
IPX port addresses. Another difference is that for IPX, a SUBNET n > x , rather 
than SUBNET^ would be used in Step 3 of Figure 4. 

It will be apparent from the foregoing discussion that there exist only 
20 minor distinctions in the process of building the SPT among certain different 

protocols If the process of Figure 4 was building an AppleTalk SPT, it would 
step through AppleTalk port addresses. Another difference is the function 
"subnet*' which is specified in Figure 4 at Step (3). For the different protocols 
there are different subnet functions. We described earlier that for IP the port 
25 addresses which are given by an address and mask - the invention applies the 
mask using "bit-wise AND," and then does the comparison to get the subnet 
from the mask/address combination. For IPX, the condition is much easier. 
The invention simply uses the address specified in the port address which is the 
IPX Network Address. Once again, referring to Figure 7 A, the region labeled 
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(7), note the address is 9C. Next reference Figure 8J anH „ K 

subnet is simp, y the network number 9Q W 8J - *"« - *e 

Thus, a S ig nificant advantage of the processes and structures of* 
Present invention over earner network management tools , 

populate the SROs. When the SRHc , «n router to 

•hol e ^ 8M "* ™- <°°«~s even 

ta* thev are no, connected „ this ^ 

configurations into SRO's- makpmo^r • 

•he networks ^*"^7 "° "* .0 oe sure 

y c properly, and perform analvsk of th-» «~ i 

form a topotegy u „,ess ,he ,w 0 networks are mer8ed 
F.gure 9 „ ows an of Buiw 

* H- process ,„ Figure , hand|es , . ^» 

misconficuration that possible, due to 

address ™ 11 " ^ " *«« «» — 

manager warns ,o correc, on the network without dday The probj 

~ ana.ogoustoasituation where, you are J^^L 
Peop, ^ *. «, same address „ ^ ^ dear ^ - - w 

^n„ g ,he process of for mi „ g , he topolosy , , ^ . * « 
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Focusing now only on the additional steps add in Figure 9, Step la, is 
inserted between Step (1) and Step (2). Step la sets the duplicate address set 
to empty. The process in Figure 9 will produce not only the SPT, but also an 
integrity check output set that conveys which port addresses refer to the same 
5 address. The comments on the bottom of Figure 9 provide an example of what 
this set might connote. For example, consider the DuplAddrSet (which is a set 
of sets) with elements {PA1, PA3, PA4} means that the port address pointed 
to by PA1, PA3, and PA4 all refer to the exact same address. Similarly, the 
presence of the second set, {PA9, PA7} means that PA9 and PA7 refer to the 

10 same address. As conflicts are identified, the set DuplAddrSet will grow. 

In Step(3 A), if the process finds that the subset of the port address 
being processed is already in the SPT, then it is necessary to determine if in that 
SPT there are any duplicate addresses. (If the subnet is not in the SPT, it is not 
necessary to do the check since an address equal to PA cannot be in the SPT.) 

15 If there aren't any duplicate addresses detected in Step 3(A), the answer will be 
"NO" and we process as normal, going to Step(4) as it appeared in Fig. 4. 

Now, back to Figure 9, Step 3 A; if the test in this step detects an 
address conflict, then processing goes to Step 5. Step 3b is a test that checks 
to see if already, in DuplAddrSet, there exists a member (i.e., a set of port 

20 address pointers) having same address as PA, the current port address). If the 
answer is Yes, then the matching element is extended to include a pointer to 
PA. If it doesn't, we add a new member to DuplAddrSet containing a pointer 
to PA and a pointer to the port address in SPT exactly matching PA. Thus, 
Steps labeled (la), (3a), (3c), (3b) and (3d), are added in Figure 9 to look for 

25 duplicate addresses and put them in this duplicate address set, DuplAddrSet. 
Referring to Figure 1, note that the invention forms topology 
information and then determines whether there are any integrity violations (Fig. 
Id and Ig). The address set is the result of one of the integrity checks referred 
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in F.gure Id. This „ imponm inbnimim ^ ^ _ 

■o find ,f .here are problems and remove then, ^ 

F.gnre ,0 show, a procedure for cafe-fating another ^ check 
wh,ch ,s apphcable to rp usi „ g „ spT fa ^ 

■ - tha, two do „ 0 , ^ aJ^CnuoZ H 

erup„a,, - We don, want the case where C 

F.g„re .0 •Kus.ra.es . general for ^ 

~~Hpp.« B Address Range „ iMegriiy co 
protocol,, ^h . ,„ Md ^ ^ ^ jnterfaces to ^ ^-r 

ddre„ rMecs (Nolc an lp ^ ^ ^ ^ ^ « * 

correspond^ to an address range) 

The .nr., ,„ ,he "Overlapping Address Range- flowchart is the SPT for 
^ ~ ana.v.ed, wh,C for „ imattloa ^ ^ , p „ 

- «. c r e 21 : r conflic,s is » - «*» 

me vanable Conn is set to the «terr.nri ^ 
(Note if, k~ ■ second connection in the SPT 

that Hiffi»~ r y part of the algorithm 

ha. d.rTers from protoco, to protocol. ,„ Step (4) the algorithm checks if ,h 
■ast connection has been reached; if so, processing termiltes "f o7 

repeats for tins new connection starting at Step (3). 
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The overlap function for IP (shown in the first box in Fig. 10) takes as 
arguments two IP subnets, each which is given by a 32 bit address and 32 bit 
mask. The subnet given by [Al Ml] defines the range of addresses from Al to 
"(Al | ~M1)'\ where T refers to bitwise OR and to bitwise negation. The 
5 expression "(Al | -Ml) can be thought of producing a 32 bit number formed 
by flipping the bits in Al that were masked out (which are the ones where Ml 
has Is) from 0s to Is. The definition for OverlapIP([al ml],[a2 m2]) can be 
interpreted as saying that subnets [al ml] and [a2 m2] overlap if and only if it 
is the case that they are not equal and not disjoint; now two addresses are 
10 disjoint if the lower bound of one of the ranges is greater than the upper bound 
of the other. 

The overlap function for AppleTalk (shown in the second box in Fig. 
10) takes as arguments two Appletalk "subnets", each which is given by a 
lower and upper bound giving a cable range. The definition for 

15 Overlap AppIeTalk[[cbrlbl cbrubl], [cbrlb2 cbrub2) can be interpreted as 

saying that the cable ranges [cbrlbl cbrubl] and [cbrlb2 cbrub2) overlap if and 
only if it is the case that they are not equal and not disjoint. 

Remember that we are sequentially moving through overall the 
processes described in Figure 1 . We have already talked about the process of 

20 taking text configuration files or MIB data and producing SROs (Fig. la). 
Given the SROs, for each of the protocols that running on the network, 
individual SPTs are formed (part of what is done in Fig. lb). Given each of the 
individual SPTs, there are a number of integrity checks we apply (some of what 
is done in Fig. Id). For each SPT, duplicate addresses are identified in the 

25 associated protocol. Additionally, for IP, overlapping subnet masks are 
identified. 

Next, we provide examples of the production of views in accordance 
with the process represented in Figure 1c. The first example is illustrated in 
Figure 1 1 . The term "view" as used herein means an abstract representation of 
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routers and LANs shjuv th* «, Ic " 
u L,/\ris snare the same campuses. In Figure 11 ™~ «u 

labeled C2 C 1 and C W i, • ' Sh ° W cam P"ses 

C2, C 1 and C3, each contaming routers and LANs. Referrins to C2 
first, we see that routers R3 R 4 an rf p-, herring to C2 

Ca.pu, C2. Reft,™ 7 " ™ ~ - 

n-erernng to C3 next, we see that router rswd, 

together and if we look at Cl weseethatth 5 anc * ^ 6 are grouped 

Rl Tr» w , '-^ s ee that there ,s one router in this campus 

R 1 To understand how this information is „ ^ ^ 

accordance with the invention, refer to Fi eure 12 „• 

of a «v.„ «-io figure 12, which provides an example 

secure Rework is used for the diffcrem ^ «** 

d.s.m 8 u,sh„f rom different views, such as the OSPF view J" '° 
"Group", is a ,is, ejects, each of , hem whffl « ~- 

shows how the routers link, and ] AN • P ' Wh "* 

«ie.o R e,her Co k \ """^ ""«««*«*». "Connexions" 

2 . S 10 R8Ure ,2 ' refer '° «— ' (» which 

refers to an ob ect withnamon tu wnicn 
J w,th name C 1 The next attribute Conn refers to a list of 
pointers to connections in the SPT being abstracted Th 
'^™th^^ 

C - . we see that the Conn.3, which JLj^^^^T 
member InFieui-Pii *h; 1 l0 - 20 0 0 . is a 

F,gure 1 1 , this ethemet is within the C 1 campus grouo Cm 

have two parts, the connections and the routers In Cl of F ^ 

of*, d"! F ' 8Ure 12 referenCe ^ <2) indiCateS ' SPT Many 

of. he data structures of the present e m bodin K „, of „,e invention are 

= data stores tha, connect the toxica, .n^tionl the SKO 
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Referring to reference numeral (3) in Figure 12, a group corresponding 
to campus C2 is shown. The connection that belongs to it is Conn[l] and the 
routers that belong to it are R2, R3 and R4 (shown at Point (4)). The last 
group (reference number 5), corresponds to campus C3; it has three 
5 connections associated with it, Conn[5], [6], and [7] and two routers, R5 and 
R6. Note that a view might not contain all routers or all connections that are 
contained in an SPT. It merely describes the elements that are relevant to the 
abstraction. In a campus view, some of the connections may be omitted. 
Connections belong to a campus view only if they are LANs. So, for example, 

1 0 Conn[ 1 ] in Figure 1 1 is a FDDI and is in C2. We see that Conn[3] is an 

Ethernet, and that is in CI; also connections Conn[7], Conn[6] and Conn[5], 
which are all Ethernets, are in C3. There are two connections, serial links 
(Conn[2] and Conn[4]) in Figure 1 1 that do not appear in Figure 12, because 
serial links do not belong to a particular campus; rather they span campuses. 

15 Figure 13 is a flowchart that illustrates a process for constructing a 

campus View object given as input, an SPT and the SROs that are pointed to 
by the SPT. In Figure 13, we refer to SPT p , where "P" can stand for any 
protocol since basically the same is used for multiple protocols, e.g., IP, IPX, 
AppIeTalk, etc. 

20 Referring to Figure 13, we first initialize the view object (VW) to 

"empty" and set Type to "campus". Next, at step (2), the variable Conn is set 
to the first connection in SPT (really SPT p ). In the following discussion, realize 
that the view object formation process iterates through all the connections in 
the SPT under consideration. 

25 In Step (3), we ask whether the Conn variable is associated with a 

LAN. If the answer is "no", (in other words, Conn is associated with a serial 
link or any other wide area link) then the connection is ignored and processing 
goes to Step (4), which asks whether the last connection in SPT been reached. 
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If « has, .he procedure termmates. ,f it ^ not _ tlm ^ fe ^ ^ ^ 

connection in the SPT, and processing goes back ,o S.ep (3) 

On the other hand, a, Step 3. if the Conn is . LAN connection, we go 
» Step („), which asks whether ,„ ere , a group in a ^ ^ 

or tnore routers in common with those pointed by Conn (Remember tha, 
Conn is a connection in a SPT, which has pointers to port addressees, and each 
port address belongs to a router,. If me answer is "yes", then we g„ „ Step 
( and add to this existing group i„ , he ^ . poimer ,„ Conn ^ ^ 
attnbute and powers to aii routers associated with Conn under the Router lis, 
- a,«n„u«e. Iftheanswer to Step 6 is "no", then processing goes to Step W 

where we create a new group. We rive each »™,,„ . • 

"eg'*: eacn group a unique name, (Campus 

C . , Campus C2, etc., We add a pointer to Conn connection and ,„ a>, routers 
pomted to by this connection After this step, we go back ,o Step (4) and And 
out ,f we reached the las. connection ,f no, i, CTate to me m 
Snarly, after Slep (7), we go back to Step (4) ask whether we have reached 
.he Ms, connection If no,, we continue to process connections until we have 
processed them ali. So, the result, upon answering "yes" in Step 4 is that the 
process terminates and the object WV (the view object, will be fully 

initiated For example, for the t^twork view in R g ure „. we have a view 
object like that in Figure 12 

We will next provide an example involving the formation of an OSPF 
v,ew. OSPF is a particular routing protocol. See, Spohn, Darren L., "Router 
Protocol, Data Network Design, pp 192 . 213 . McGraw-Hill Inc ,993 
Also, see the following Requests for Comment issued by the Interne, 
Engineering Task Force (IETF,: RFC 1 77 1 - A Border Gateway Protocol 4 

(BGP-4) specification: RFC 1 13 1 - OSPF * nar .;a 

, v*-v. i visrt specification; and RFC 1058 - 

Routing Information Protoco. (RIP,. Basically, routers run routing protocols 

m when they exchange and generate information to produce routing tables 
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For OSPF, a network is grouped into areas with some routers called area 
-border router, responsible for exchanging information between areas. 

Figures 14 through 17 deal with creating an exemplary OSPF View. 
Figure 14 gives an intuitive picture of an exemplary OSPF view. Figure 15 
5 shows an example of a data structure that captures the OSPF view of Figure 
14. Figures 1 6a and 16b are portions of the SROs for the routers shown in 
Figure 14 that are relevant for the analysis. Finally, Figure 17 is an IP SPT that 
was formed for the routers in Figure 14. 

Referring to 14, there are two Areas, Area 0, (encompassing routers 

10 Rl, R2 and R3) and Area 1, (encompassing routers R6 and R5 and a group 

with a single router 4) which is the area border router between Area 0 and Area 
1 ; to be more specific, R4 is running both Area 0 and Area 1 . 

Referring to Figure 1 5, there is shown a View data structure that 
captures the grouping of Figure 14. The View object Type is OSPF. The 

1 5 View object's TYPE attribute distinguishes it from other View objects, such as 
the campus view TYPE. Next, note the groups attributes. The group attribute 
comprises a list of group objects. The first group refers to Area 0, the 
connections in that group are, Connp], [2], and [3], and the routers in the 
group are, Rl, R2 and R3. The next group refers to Area 1 , which includes 

20 Conn's [4] thru [7] and routers R5 and R6. Finally, there is a group for the 
area border router R4. 

Figures 16a and 16b illustrate how router configurations as captured by 
the SROs contain the information that is used to indicate which areas the 
different routers correspond to. In Figure 16a, we see that the SRO for router 

25 Rl is running an OSPF process, OSPF I . Note that a router can be running 
many different OSPF processes. For simplicity here, we only consider cases 
where a router runs just one process. At reference numeral (1 ), we see that the 
OSPF process on router Rl has an attribute called Net Address, which refers to 
a list of statements indicating what areas the different router interfaces belong 
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network statements for router R4. The first network statement reference 
numeral (2) shows the pattern 98.40 (ignore the rest of the bits). This matches 
Serial O's address (98.40.10.1), and thus this interface is in area I. However, 
FTs address (20.20.10) does not match the first network statement, (the 
statement at reference numeral 2 in Figure 1 6a), but the second network 
statement matches 2b. Thus, Fl (from router R4) is in the area specified by 
network statement 2b, i.e., Area 0. 

For the routers running OSPF, determining what areas their interfaces 
match is an important step in the algorithm for producing the OSPF view. 
Very briefly, if there is a router that has one or more interfaces, all of them 
belonging to the same area, then this router will be put in the group for this 
area. For example, you see that routers Rl, R2 and R3, in fig. 14 have all their 
interfaces match a statement associated with area 0. On the other hand, router 
R4 has interfaces that match two different areas, so it is in its own border area 
group. Similarly, routers R5 and R6, have all their interfaces match area 1 . 
Thus, R5 and R6 are in area 1 . 

An advantage of multiple views is if you have a particular task at hand, 
then a specific view might be particularly suitable. The OSPF view, for 
example, is a view that would be useful for configuring OSPF. In configuring 
OSPF, a central concept is specifying what areas each router, running OSPF 
belongs to. So being able in a very succinct way, to observe the area groupings 
is an enormous benefit in gaining a more comprehensive understanding of how 
the OSPF processes are running. 

Placing a router in the wrong area is a very easy mistake to make. For 
example, in typing in a configuration, a user's mistyping 1 instead of 0 in a 
single area statement changes what areas a router's interface is in. Thus, it is 
very helpful to have a view based upon OPSF areas to permit easier diagnosis 
of errors, for example. 
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or more areas associated with a single connection, then Conn processing from 
Step (5) goes to Step (6) where the connection Conn is put in OSPF conflicts. 

Another case arises when the connection is only associated with one 
area in which case the process continues to Step (8). In Step (8), just for 
5 convenience "AreaAr" refers to the case where there is a single element in 
AjeaSet 

After Step 8, processing proceeds to Step (9) which asks whether the 
area associated with connection Conn is already in the view. If it is in the 
Vi<r*. then u c want to add this connection under this area which is 

10 accomplished at Step (10). On the other hand if the area associated with Conn 
is not in the view, processing goes to Step (1 1) where a new group labeled 
"Area Ar" is created and under which there is added a pointer to Conn. From 
both Steps (11) and ( 1 0), processing goes to Step (12). 

Steps (12) through (17) are responsible for putting routers pointed to 

1 5 by Conn under the appropriate area if they have not already been placed. 

Recall that a connection points to a set of port addresses, each one of them 
corresponds to a router. We set variable PNTR to the first pointer in Conn at 
Step (12) We then go on to (13), which asks whether a router associated with 
this pointer is in the View already". If the answer is yes, then we do not have 

20 to process this router and we go on to Step ( 1 6), which asks whether PNTR is 
the last pointer in Conn. In other words, it asks whether we have finished 
processing the routers in Conn. If that is the case, then we go on to Step (7) to 
process the next connection. If not, we go on to (1 8) to process the next 
pointer (more particularly to the router pointed to by this next port address 

25 pointer and go back to Step (13)). 

In Step (13), if the router associated with PNTR has not been 
processed already, we go to Step (14) and ask how many areas the router 
pointed to by PNTR has. Figure 20 shows detail of how the answer to this is 
computed. If the answer is zero, in other words this is a router which is not 
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border routers, and hence belongs ,o i,s own group 

Figure ,9 is a flow char, which explains details of Step <«> in pig,,,., „ 
■ « , a procedure, which gtven as ,»pu, a pabular Coi , nectio „ „ . ^ 
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»™ Ri s,he ,as, pointer. Conn. .H. is, then processing is fin^ 
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in CONN. The process then returns to Step (2). Q „ the other hand if the 
given router has OSPF configured, Step (5) is reached 

Note that for simplicity we assume that . ^ ^ 
Process, if i, has any The actua, indentation of the preferred embodiment 
owever can handle multiple OSPF protocois on a single router, and this 
process described herein naturauy extends to cover that station 
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to Step (6), which asks whether the OSPF _obj has any network statements. If 
the answer is "no", then the process go back to step (3) and iterates through 
and processes the next router. If the answer is "yes" then "Netstmt", becomes 
the first "network statement" in OSPFobj. 
5 In steps (7) through (1 1), the process goes through sequentially the list 

of network of statements associated with the OSPF process to see if the 
address associated with PNTR matches one of those statements. If so, then the 
process uses the area number associated with that network statement. At Step 
(7), the process makes Netstmt the first network statement. Step (8) asks an 

1 0 address associated with PNTR matches the network statement". The details of 
this matching process are described earlier in this specification. If there is a 
match, then the process proceeds to Step 1 1 which adds the area mentioned in 
the network statement to the output AreaSet if it is not there already. 
Processing then goes back to Step (3) to process another router, if any are left. 

15 On the other hand, if at Step (8), the address does not match the network 

statement, then the next OSPF network statement is processed, looking for a 
match, if it exists. 

Figure 20 depicts a flow chart that describes in detail Step (14) in 
Figure 18; it asks how many areas a particular "router" is associated with. We 

20 contrast this with the process in Figure 19 which is the question: how many 
areas a "connection" has associated with it. 

The first step in Figure 20, labeled (0), is to set the output AreaSet to 
empty. The process next goes to Step (1), and asks "whether a router has 
OSPF configured". If the answer is "no", then the process is finished, and the 

25 output area set is empty. If the answer is "yes", the process proceeds to Step 
(2). For convenience the variable OSPF_obj is set to refer to the OSPF object 
associated with the input router. The process then goes to Step (3) which asks 
whether this OSPF object has any network statements If it does not, then the 
process exits with the answer being that the area set is empty. If it does, the 
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( 1 0) to process a new port address. 
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depicted in Figure 35. The SPT in Fig. 35 shows that Rl's, R2's, R3's and R4's 
SO port all are attached to subnet 1 17.33.4.0. The implicit assumption of these 
four ports in the same grouping is that they all could directly reach each other, 
or in network terms, that they are "fully meshed". For a LAN this is the case; 
all the connected ports can directly communicate. 

A potential problem, however, is that in a multipoint WAN, such as 
Frame Relay for example, the connected routers may not be fully meshed. For 
example in Figure 34 we show that there is only a partial meshing. The dotted 
lines, in the Frame Relay cloud in Figure 34, are there to convey that the pairs 
of routers that can directly "talk" are: Rl and R2; Rl and R3; Rl and R4; and 
R2 and R3. This is not a full meshing, for example, because R4 cannot directly 
talk to R3 

An important aspect of capturing a Level 3 view is capturing the fact 
that R4 and R3 are not directly connected. If we use the SPT in Figure 35, we 
are not capturing that distinction. Instead, we can use the SPT in Figure 36 to 
represent this incomplete meshing. Figure 36 shows four Connections, all with 
the same subnet 1 1733.4.0. These four Connections show the directly 
connected routers in the Frame Relay Cloud. 

There are a number of sources of information about meshing in a multi- 
point WAN, such as Frame Relay. One mechanism to determine the meshing is 
by the inclusion in the router configuration text of explicit Frame map 
commands. Looking at Figure 38a at reference numeral (1) there appears 
command, "Frame Relay Map IP", and the address 1 17.33.4.2 and the number 
100 (and the term "broadcast" which is not relevant to the disclosure). This 
command which is associated with router Rl's SO port is saying that SO is 
meshed with the address 1 17.33.4.2, an address of R2. So, reference numeral 
(1) in Figure 38a corresponds to the dotted line marked (1) in Figure 34. 
Similarly, referring to the second line under the Frame Relay Command, in 
Figure 38a, we see mention of address 1 17.33 .4.3 which corresponds to the 
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doued hne ,ha. connecs R1 to w in Kgure 34 ^ ne;a (o 

a. referee numeral (3,, we see the mapping from R1 to ^ „ ^ ' 
■recuon: fromR2toR1 . lnsummwy , he presence ^ themapcoraman 

™er con^on files is one source of informa , ion (o 
- Frame Re!a y cloud, for example This information often can be obtain* 
from .ex, flies, «h as .hose shown in exemplary Figures 38a .hrough 38d 

In F,gure 37 there is shown a fag™, of , he SRO for ^ 
focuses on how the Frame Relay maps in Figure 38a , ra „s,a.e , nto the SRO 
Referrmg to reference numeral (, ), „„ K lhat Ihere is „ atrtbute for so 
wh,c„ is a fa „f Frame Relay map objecs. ,„ Figure 37, each one of .hese ' 
«ems under Frame Maps iabeted (1) which hems are labeled (2), (3) and (4, 
correspond .o ,he .hree Frame Re,ay Map commands ,ha. are presen. under' 

S ° " Fi8Ure 38a " is a ^-forward t ransla.io„. Another 
process for determining the meshing j. a m ul,i-po,„, WAN is referring to the 
i.« router and executing a "Show Frame Map- command, parsing the response 
and bringing it in the SRO. 

To handle the complications due ,o a multi-poin, WAN we have to 
modify the SPT algorithm ,ha, we descnbed in Figure 4 To show how we 
"toddy this algorithm, we repeat diagram 4, .abehng , he boxes with letters 
rather than numbers, which is given in Figure 3 1 We show the additional ' 
processing steps, labded with numbers, tha, modify i« (Figure 32) and .hen 
we „ jus, apply ,he modificauons and .he show ,he resulting flowchart (Figure 
3). n F. g . 33, the previous s,eps are labeled with letters, while the new ones 
are labeled with numbers. 

Referring , 0 the Step labeled (C) in Figure 32, which is the same as 
S ep (C, ,„ Figure 3 , Step »C» is a tes, ,o see if , he subne, for the port 
^ress being processed (PA, is i„ the SPT. If ,he case is »„o» U,e„ we go to 
<D>, wh,ch is normal processing, and reiterate the process with ,he nex, per. 
address. On ,he Cher hand, if .he Subne. (PA) is in the SPT, processing goes 
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to Step (1 ), which asks whether the port associated with the PA is Frame Relay 
encapsulated. This is determined by looking in the encapsulation attribute of 
the port associated with PA in the SRO If this is not the case, then normal 
processing takes place and the procedure goes to (E) (again as depicted in 
Figure 31). If not, go to the special Frame Relay multi-WAN processing, in 
other words we go to Step (2). In Step (2) the variable FRM is set to the set 
of Frame Relay maps associated with PA's port. The process iterates through 
this set by first setting FRM_ member to the first element of FRM (Step (3)). 
In Step (4) for convenience the variable ConnSet is assigned to the set of 
connections in SPT that i) match subnet (PA) and ii) have the property that it 
has a pointer exactly matching the address in the variable FRMmember. Now 
it's possible this set could be empty. Step (5) asks whether the Conn Set is 
empty. If the answer is yes, then go to Step (10), which asks whether there is a 
connection of SPT matching Subnet (PA) with just a single pointer to PA. If 
the answer is "no" go to Step (9) and add a new connection with subnet Subnet 
(PA) and with a single pointer to PA. Then go to Step (1 1 ) to determine if the 
last frame member has been reached. If not, continue in the loop, going to Step 
(12) to set Frm member to the next element, and continue processing. On the 
other hand, if the answer is "yes" at step (11), then processing of PA is 
finished. Then go to Step (F), which is in the original Figure 3 1, to process the 
next port address. Now, on the other hand if the answer is "yes" at Step (10) 
i.e., there a connection in SPT matching subnet (PA) with just pointer to PA, 
then go to Step (11) and continue in the loop over Frame members. 

Now referring again to Step (5), if ConnSet is not empty then we go to 
Step (6), which asks whether there is a member of ConnSet having just one 
pointer. If the answer is "yes", add a pointer to PA to this member, (step (7)), 
and then continue to Step (1 1) to process the remaining elements of FRM. If 
the answer is "no" then go to step (8), and create a new connection whose label 
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» ( PA) , Md under this we add ,„„ pointere: one to pa ^ ^ other 

the port address corresponding to the address in FRM member 

the add,Uonal steps to handle multi-point WANs, (Figure 33) we'.! walk 
through a specific example, the one that's intuitively depicted in Figure 34 
whose conjurations appear in Hgures 3 8 a through 38d and having an SRO as 
shown ,„ F.gure 37 (Figure 37 shows o„,y one of the SROs (for Router R1)) 
We do no, include the SROs for Router R2 through R4 because the process of 
g o,ng fl-on, . config file to , SRO representation for these routers should be 
\u evident. 

Figures 39a through 39f provide a detailed example used as a 
walkthrough of the flow chart depicted in Figure 33. 

Starring a, Figure 39a we see reference to Step (1) of the of 
F.gure 33 where tne output, the SPT, is initialized to the structure shown 
opposite Step (,) This is an IP SPT. So the protocol is set to IP .„s,ep(2) 
PA ,s set to the firs, port address, 1 ,7.33.4, , 255.255.255.0. At Step (3, the 

question is whether subnet (PA) which isiili!d» - .. „„ 

v wmcn is J I 4.0, is in the SPT. In this 

case it is not because the SPT is emntv tk,,, 

e sr l empty Thus, go on to Step (4), which adds a 

new Connection, whose subnet is ! ,7.33.4.0, to the SPT. Then go to Step (9) 
wh,ch adds a pointer under this subnet to R,, SO.BM (,he current port 
address). Referring to Step (9) in Figure 39a, there is shown the structure 
formed by Step (9). After Step (9) go to Step ( , 8), which asks whether PA is 
•he las, port address. The answer here is "no" Processing goes to Step (19) 
where PA is set to the next port address, 1 17.33.4.2 255 and 255.255 0 After 
Step (19). go to Step (3), which asks whether subnet (PA), (, , 7.33 4 0) is in 
•he SPT. The answer here is -yes". ,„ Figure 39b, there is a continuation of 
*e walkthrough continuing from step (3), which answered "yes" Thus , ne 
current step is Step (5), which asks wh«her PA is Frame Relay encapsulated 
The answer is "yes- Thus go to Step (6, and set the variable FRM to the se, 
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of Frame Relay map addresses associated with PA's port. In this case there are 
two of them, 1 17.33.4.1 and 1 17.33.4.3. Then go to Step (7) and set 
FRM_member to the first address, 1 1 7.33.4. 1 . Then go to Step (8) and set the 
variable ConnSet to the connections in the SPT matching subnet 1 17.33.4.0 
5 with a pointer exactly matching the Frame member. In this case, ConnSet 

contains Conn[l] because this has the subnet 1 17.33.4.0 and also has a pointer 
toRl,S0,IPl whose address is 117.33.4.1. 

Next, go to Step (12) which asks whether the Conn Set is empty. Here 
it has one element and so the answer is "no". Step (15) asks whether there is a 

10 member of ConnSet having just one pointer. The answer here is "yes" because 
Conn [1] only has one pointer. Thus go to Step (16) and add a pointer to PA 
under this connection forming the structure shown at (16) in Figure 39b. Then 
go from Step (16) to Step (10) which asks whether the process has reached the 
last member of FRM. In this case "no" because there is one more element to 

1 5 process. So, the answer at Step (10) is "no". 

Refer now to Figure 39c. Since the answer to (1 0) was "no", the 
current step is Step (11), and FRM^member is set to the next element of FRM, 
1 17.33.4.3. Then go to Step (8) and set ConnSet to the connections matching 
1 17.33 .4.0 and also with the pointer exactly matching frame member which is 

20 1 17.33.4.3. In this case there are no connections meeting the second criteria. 
So Step (13) asks whether there is a connection matching subnet (PA) with a 
pointer to PA in SPT? The answer here is "no". Go to Step (14) and add a 
new connection with subnet 1 17.33.4.0 to SPT under it, a pointer to PA. The 
resulting structural addition to the SPT is shown in the diagram at reference 

25 numeral (14) in Figure 39c. Then go to Step (10), which asks if the last 

member of the frame set has been processed. The answer here is u yes," and 
thus we go on to Step (18) which asks whether the last port address has been 
reached. The answer here is "no" because there are more port addresses to 
process. Go to Step (19) which sets the next port address to 1 17.33.4.3 and 
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251255.0.0. Move now ,o Figure 39d, which is a co„,i„„ atio „ of the 
Walkthr ° Ugh ™ ^er setting th e new port address irl Step * 
S.=P (3) which asks whether 4. subnet is associated with 1 "° 

(which in this case is ■ ,7.33.4 0) in the SPT ^ ^ 

} tne 5r 1 • The answer here is ( 'v^» T u 
SO to Step (5), which asks whe,her this Frame Relay m ^ ~_ 

» "y«," and thus processing goes t o Step (6 > whic sets the J 

the «>t n f* r ~ S the va "able FRM to 

Rou"^sTT a r ia,edWi,, " hiSPAPm ^re fe rs,o 
Rou erR3s SO pon.wh.ch has ,wo Frame Re hy addresses, ,,7.33.4 , and 
>«3.4. 2 . Go ,o S,e P (7, and se, FRM_member to the firs, eiemen, ofTh e 
«™eset, >n.33.4,. Ne«i n S,ep (8 ,c„ m p ulemeComSetby]oo ;; 
connect™ tha, ma,ch subnet (PA), , , 7.33 , 0, and ones ,ha, a so W a 
Pomter exaCy matching th e frame member. ,„ ,hi s case one ,, 
Connn^seirs^^ 

e:r^" g, r emera ° otos -<' 2 '---herco„: et ,e 

empty. The answer here s "no" Gn tr> ... 

tep ( 1 5 >> wh,ch asks whether there i* 

am^o fC o M Se t ha^ ju s,onep„m t e, T hea,„erhereisW. I 
Conn[„ has ,wo pomters under i t . Go on ,o Step (,7) and add a new 

connecuon whh subne, ,,7.33.4 0. and under i, add a pointer ,„ both P A 
whtch ,s K3.SWP, and ,o the pon address corres^ding to the 
FRM.memher, which is RI ,S0,,P, Looking i n Figure 39d, reference numera, 
(17), ,nd,ca,es secure add to the SPT upon competing Step (,7) 

S.ep nTl '! FiSUre 39C - ^ " 3 — ° f *" through 

S"P 00) asks whether the iast member in FRM has been processed The 

:;;;Tn Bo t ostep(,,) '^ F ------.o.his„e M :ie„, 

> 1 7.33.4.2, to the firs, ,P address on R2.S0. Next a, Step m r„ 
matching 1 1 7 33 4 0 with „ „ ( Com,ectlo " s 

1,7334 , , t W " hap0,n,erM « Ml >'^» g .l.eF R M member 

T s h CO " nSet ^ ™ «™< «** " Con„ (21 

Thus, the answer a, Step (.2) is and processing goes to Step (ls) w ^h 
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answers "yes" since ConnSet has a single member. Consequently, processing 
goes to (16) which adds a pointer to PA under this member Conn[2] leading to 
the structure in Figure 39e adjacent to reference numeral (16) After Step (16), 
processing goes to Step (10) which asks if the last FRM_member in FRM has 
5 been processed. The answer here is "yes". Hence go to Step (18), which asks 
if the last port address has been processed. The answer here is "no". There is 
still one more port address to process. Step (19) sets variable PA to the next 
port address which is 1 17.33.4.4 and 255.255.0. Next, Step (3). At step (3), 
the answer is "yes" since subnet (PA) which equals 1 17.33.4.0, is in the SPT. 
10 We then go to Step (5), which answers "yes" since PA is frame relay 
encapsulated. 

The walkthrough example now continues with Figure 39f. Step (6) sets 
FRM equal to the Frame relay maps. In this case it is a set having one element, 
117.33.4.1. Go to Step (7) where the FRM_member is set to the first element, 

15 which is the only element, 1 17.33.4. 1 . In Step (8) look for the connections 

matching subnet 1 17.33.4.0 with a pointer exactly matching FRMmember. In 
this case two matching elements are found: Conn[l ] and Conn[3]. Step (12) 
asks whether the set is empty. The answer here is "no" because it has two 
elements. Go to Step (15), which asks whether there is a member of ConnSet 

20 having just one pointer. The answer here is "no". The two elements both have 
two pointers. Go to Step (17) which adds a new connection with subnet 
1 17.33.4.0 and a pointer to PA, which is R4,S0,IP1, and also to the port 
address corresponding to FRMjtiember, which is R1,S0,IP1 resulting in the 
SPT structure shown adjacent to reference numeral (17) in Figure 39f. Go to 

25 Step (10) which asks if the last member of FRM has been reached. The answer 
here is "yes". Go to Step (18) which then leads to termination of the procedure 
since the last port address has been processed. 

Next we shall discuss the construction of the MPT, which stands for the 
Multiple Protocol Topology. Referring to Figure lb, the MPT is constructed 
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dara s^rure *« cap, ures ,he inlCTrelationships ^ , he J 
opo, ogl c hofwhichisaicodedasanSpT W.3 

Pon can have mufcipie « , addreSKS ^ ^ 

protocois. When .here are m„, tipl e addresses from differ,, 

•o ™.er s p„r,s i„ the neIwork there , potemia| for ~ 

incompatible addresses. 8 h 

such a s l^PX T " inCOmPa ' ible iddrKSeS " — "» 3 ""«~* 

■ - ™»p» „ a ne,wor k with incompaubie addre.es is shown in Figure 26 
-ch show, a nerwo* wnh mismatched „, ^ ^ * ^ 

•PX connect .ha, wouid be flagged „ being a Mismatch ^ - 
shown m y 23 The _ Iha , ^ ^ comections ^ 

rr::; yove *^^ eofh ^-^--«><-^4 
d rr n as *• iabe,ed w Md a,M ^ « 

hus and FPX connects are i„ conflic. Looking „ the „ 
Vwe see .ha, .his conrlic, is irnportaw to ^ ^ * 

Leve, T" ^ ' >Ui ' d '" 8 ' ^ 3 SM ° f SPTS ' «"» each 

°" network) - cmain ^ «*» 

2 SPTs can he .denied ,hrou 8 h certain ^ checks . 

- . con™, pracce ,o do, which cheese g rea, ly tapr0V es the abilhy to 
-age ,he nerwor, Because i, is _ pracice ,o have iogica, ^ 
wuh compare addresses, finding ,he conflict b e,wee„ ,ogica, ^ ~ 
oe an ccre-neiv va,ua b ,e diagnosUc aid ,ha, can iden,i* address,»g erroT 2 
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mentioned earlier, it can be important to identify addressing errors because they 
can have substantial impact on network operations. An important benefit of 
computing how logical topologies relate is that information regarding one 
logical topology can be used to fill in missing information about another logical 
5 topology once they are synchronized. We will show, later on, an example of 
how information that would be missed by just looking at the IP topology alone 
because of a Cisco configuration command called IP-unnumbered could be 
filled in bv using logical topologies from the other protocols such as IPX and 
Appklalk The production of the MPT is a unique aspect of the invention. 

10 The MPT serve* to coordinate topologies from different protocols. 

Figure 2 1 provides an illustration of a MPT data structure, in attribute 
form A MPT structurally looks very similar to an SPT. A MPT consists of a 
list of objects which are called Multiple Protocol Connections. In Figure 21, 
reference numeral (I) indicates a first multiple protocol connection labeled 

1 5 MpC[ 1 ] This object contains a list of subnets that it refers to. Each subnet is 
from a different protocol. Note also that, for IPX for example, a network 
number would be included in the list. So, MpC[l] could have an IP subnet and 
an IPX network number. A multiple protocol connection object also contains a 
list of pointers, not to the port address on a router, but to the port itself. So, a 

20 pointer for a MpC is identified by simply a router and a port. It does not have 
the additional attribute that SPT has which identifies a particular address within 
a port So one could think of a MPT as tying together router ports and 
grouping them together in the different protocol (sub)nets that correspond to 
each other 

25 Figure 22 is a flowchart that computes a process which produces a 

MPT from a set of SPTs denoting the different logical topologies. In addition, 
during formation of the MPT the process will also find mismatches between the 
topologies, which are put in a mismatch set which is another output for this 
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pro^ .denuding ^ . a partjcu]ar 

accordance with the invention 

Note that though Figure 22 only handles p 
•ne process . easiiv generahzed to handie other protoco., For e Xarapl e^ 
— bas,c process can be used to process IP , IPX and Am * "» 

In Steps (,) and <,a), 4. two outputs of the pr0MSS , he 
M,s ma « .etareinitia.i.edtoe.ptv The firs, par, of the P rocess ^ 
denoted by Steps p> through (5) , handies the ,P par t, and lhe „ 
Process handies the rPX par,. For the ,P par,. . re ,a t , vely ^ p ^ f 
used whirh e^r^i-"" ^ • * - Process is 

-C- m ,." r ' P S,n,CtUre imo "* ^ Step (2, sets 

C to kefirs, connection in the ,PSPT Step (3) adds into MPT a MpC 
corresponding to this connection. Step «) asks whelher ,. c „ , * 
connecon in SP V if »C" is the ,as, ,P conIKCtlon , the „ gQ , o " 
C ,sno„ he ias. ,P Connection, go to Step <5> an dset Co the nex P 

connect™ and repeat the process. When S.ep (6) is reached the ,P SPT has 

been "copied" into the MPT. 

.PX PT ,„,o the MPT. and aiso ,oo k for conflicts. ,„ these S,e P s. variahie 
C . used to .terate over the ,PX connections. Step (6) sets ^ t0 lhe ^ 
-PX Connecuon ,„ the rP X SPT . Step (7) ^ whaher 
C nnecon C with the MpCs in the MPT ( which a, this point i„ ,he p^ 
merely reflect the IP SPT structure ) 

^result of the match process is one of four states. One state is a 
contpiete match, another one is a mismatch, connoting a prohiem, anolltate 

uo to Mep (1 1) to determine if C is the last IPY 
connecon. If iUs, the process terminates, if no,, set to the nexUPX 
connecon and go oac k to Step (7). If there is a compiete match in s.e^ 
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then there is an IP connection and an IPX connection that correspond to the 
exact same router ports. In that case, go to Step (8) which adds a new IPX 
subnet to the matching MpC Then go to Step (11), etc. iterating through the 
loop. On the other hand, if there is no match or if there is a subset relationship 
5 in Step (7), then go to Step (10) where a new MpC is created by "copying 
over" the IPX connection "C" Next go to Step (1 1). If C is the last IPX 
Connection, then the process terminates. If not, go to Step (12), and iterate 
through the rest of the IPX connections. 

Figure 23 is a flowchart that provides additional details about Step (7) 

10 in Figure 22. The input for this flowchart is "C", which refers to an IPX 

connection, and the MPT. The process starts at Step (7a) where MPNTR is 
set to the first connection in MPT. Step (7b) asks whether the IPX connection 
intersects the MPNTR. As used herein, the term "intersect" means "refers to 
one or more of the same ports." If the answer is "no", then Step (7h) asks 

1 5 whether MPNTR is the last MpC in the MPT. If the answer is "yes", then all 
the connections in MPT have been processed, and no matches or intersections 
have been found. The process exits with status: completely no match. If there 
are more MPCs to process, then set the variable MPNTR to the next 
connection in MPT (Step 7) and go back to Step (7b), 

20 If at Step (7b), an intersection is found between "C" and MPNTR then 

go to Step (7c) which asks what type of intersection relationship is present. 
Specifically, the question is whether there is a one to one correspondence 
between MPNTR and "C'\ That is, do they point to the exact same router 
ports? If the answer is "yes" then the process exits with status: a complete 

25 match. If there is not a one-to-one correspondence, then Step (7e) asks 

whether the ports in "C" refer to a proper subset of the ports referred to by 
MPNTR or visa versa. In other words, do we have a subset relationship? If 
the answer is "yes" then the procedure exists with status: subset relationship. 
If not, the process exits with a mismatch status. 
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F«« 24a through 24i, i llu stra,e a walkthrough examp|e 
flowcharts of Fjgures 22 and 23 . The 

F.gurcs 24a through 24i uses as i„p ut ,he ,P SPT in Figure 8j ^ ffx spT 
» F-gure Sj Recall ^ these spTs ^ from sROs • ™ *T 

Figures 7a and 7b. T ' KSROs - i "»"-ep re sc™ t herou t er c „„ figuration(iles 
sWn - Figures 6a and «, Recall tha , Flgure s is imend<jd ^ * ^ 
illustration of the routers in the network. 

Kef™, to Figure 24a, the diagram shows the state of the output 
MP. ate Step , , , ,„ Figure 22 is executed Referent numera , in ^ 24 
indicates tk*i St~wi^ • ^ m . s CZ4 

- - - <■<""> "gure 22, MisMatch is initialized to empty 

Step «s -C to the firs, ,P connection in SPT IP, C o„„(,] in Figure 8i 
whose subnet is 10 30 0 0 Ste D m»,M, . 

the MPT r , . connection corresponding to «C» to 

•he MPT Flg „ r e *b shows the resulting MPT state after applying Step (3) 

marked as , , , ,„ Figure 8 , The dWerMce , , hat ^ ^ ^ ^ 

R2.B.MP,. In other words rather than pointing* a specific' 
address on a pon. a connection in a MPT just points to the port itseif 

Hgures 24a and 24b show the main operation in processing the !P SPT 
the pointers in the IP SPT are copied into the MPT, omitting their address 
references yielding pointers jus, mentioning a router and a port thereby 
pointing ,o a higher level in the SRO stiucture and being independent of 
protocol 

. y" 24c *• ^.s after proofing the next connection, 

which " Con„ ( 2, (See Figure Si). The diagram in Figure 24c shows the aate 
of , e MPT after S.ep (3, is executed the second time Once again, note the 
s.™ anty between the structure in Figure 24c and the firs, two connections in 
the structure of Figure 8i. 

Figure 24d illustrates the state of the MPT after Connm • 
Step (3). Conn[3] is processed in 
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Figure 24e shows the state of the MPT after the last IP SPT has been 
processed. 

We have now discussed the first pan of the process in Figure 22, where 
the IP SPT is copied over to the MPT, Next, the process iterates through the 
5 IPX SPT where an additional step is performed that looks for matches and 
mismatches. Figure 24f continues the walkthrough example at Step (6). In 
this part of the flowchart, the variable "C" is set to the connections in the SPT 
IPX. In Step (6), "C" is set to Connp] in Figure 8j which has (sub)net 9C. 
Step (7) determines the type of matching relationship between "C" and the 

10 MPT in Figure 24e. In this case, the result is a complete match. The reason 

that there is a complete match between the connection in Figure 8j (with subnet 
9C) and the first connection in the MPT is that they both corresponded to only 
one router port, Rl, E0. As a result, since the answer to Step (7) is a complete 
match, go to Step (8) which "adds Cs subnet to the matching MpC. The 

1 5 subnet corresponding to "C" is 9C. Referring to Figure 24f there is shown 
subnet: 9C" which has been added under MpC[l]. 

Referring to Figure 24g, Step (11) asks, whether "C" is the last IPX 
connection. The answer is "no" because there are two more IPX connections 
to process. Step (12) sets C to the next IPX connection, Conn[2] as shown in 

20 Figure 8J, which has subnet 7 A. Step (7) then asks what is the result of 

matching this IPX connection with the MPT. In this case, it is found to be an 
exact match with MpC[2]. Now, refer back to Figure 24f, which is the state of 
the MPT at the time the matching takes place. The reason that it is an exact 
match is that MpC [2] it refers to two router parts, Rl SO and R2 SO and so 

25 does Conn[2] in Figure 8j. Because there is an exact match, go to Step (8) and 
add "C's" subnet (7 A) under MpC[2] yielding the structure in Figure 24g. 
Then go to Step (11) which asks whether "C" is the last IPX connection. The 
answer is "no" because there is one more IPX Connection to process. 
Step (12) "C" is to the next IPX connection, which in Figure 8j is Conn[3], 
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wh,ch ha, subnet 98. Then go to Step (7) which once again finds „ exact 
match. Note ,ha, in Figure 8j Con„[3] has a pointer to one router port R2 EO 
as does MpC[3J as shown in Figure 24e. Because there is an exac, match go 
to Step (8) which adds "CV (Sub) ne, 98 under Mp Cf 3] yieiding the structure 
shown ■„ Figure 24h. Finally, Step ( 1 1 ) determines that the iast IPX 
connection has been reached, and the process exists. The resulting competed 
MPT is the structure shown in Figure 24i. 

Figure 25 shows the integration of the example MPT with the example 

SROs. When we presented the MPTi Mr\i*r 

p earlier there were just pointers, here we 

replace pointers with the actual SROs to better illustrate the integrated 
structure. This is a novel aspect of the invention, the fact that the object 
model does not merely manage isolated routers, but rather maintain the 
mterrelationships among routers. Specifically, the MPTs and the SPTs 
interrelate the SROs. 

Note that in Figure 25 there are two type of links connoting two 
different relationships, the single links represent a component relationship (f or 
example, the object type MPT has MPC components). The double lines 
represent pointers. A pointer differs from a component-link in that it links to a 

separate object. 

As mentioned above, one of the advantages of forming a MPT is tha, 
."formation from one .ogica, protocol can be used to fi„ in missing informa , ion 
from another logica! protocol. The following figures show how information 
that ,s omitted from the IP SPT cou,d be filed in from another protocol, such 
as IPX Ctsco Systems, for example, has a configuration option called IP- 
unnumbered, where on a particular router port, rather than explicit!, giving i, 
an IP address, the IP-unnumbered command could be used. One advantage of 
tins configuration option is tha, i, helps ,o conserve the address space 
However, a problematic ramification of using IP-unnumbered is tha, since a 
port configured with IP-unnumbered does no, have its own address, i, cannot 
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be readily matched up to the other router ports. Remember that in Figure 4, 
which shows how to produce the SPTs, a critical aspect of the SPT formation 
process is knowing the port addresses and matching them up. So, if a port 
lacks a port address, the process, in a sense, is blocked. The example network 
of Figure 28 shall be used to illustrate a procedure that accommodates IP- 
unnumbered. The example network with four routers, R3, R4, R5 and R6. 
Router R3 and Router R4 are connected through their FDDI 1 interfaces to a 
FDDI ring whose subnet is 20.20.0.0. Router R3 and Router R5 are connected 
through their Serial 0 interfaces to a serial link, which is explicitly assigned an 
IPX network number, but no IP address (because IP-unnumbered is being 
used). Routers R4 and R6 are connected through their serial 0 interfaces with 
a serial link that is given an IPX network number (9C) but no IP address. Now 
look at the configuration files for these four routers and what their SROs 
structures. In Figures 29a through 29d we show the four configuration files. 
Refer to Figure 29a reference numeral (1). Under interface Serial 0, rather than 
explicitly having an IP address with an address and mask, we see the IP- 
unnumbered command. (Note: The interface mentioned in the command, 
loopback 1, will not be further discussed because it is not relevant to the 
present discussion. However, to give a little more background or what a 
loopback is: while a router has a number of physical interfaces such as serial, 
FDDI and Ethernet interfaces, the user can manually configure as many 
loopback interfaces as he or she wants. These serve, in a sense, as a way of 
addressing a router. If a host wants to reach a router, it needs to mention an 
address on the router's ports. A common technique is to supply loopbacks to 
serve as addresses into a router; an advantage of a loopback address over the 
address of a physical port, is that a "loopback cannot fail"). 

Figures 29b through 29d each have IP-unnumbered configurations on 
their respective Serial 0 interfaces. Figures 30a through 30d show the SROs 
that are produced by parsing and filling in the defaults of the configuration files 
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•hat are shown i„ Figures 29a through 296 Figure 30a shows the SRO 
corresponding,. Figure 29a. Ifs a straightforward , ranslation. The o„,y .nine 
■o height here is the protoco, address indicated by numeral (, , ^ 

- P-Sure 30a indicates that the router is an IP-unnumbered and points toT 
■oopbackU ^.Figure 30b corresponds to Rgure 2 9b , Figure 30 
corresponds ,o Figure 29c and Figure 30d corresponds to Figure 29d 

Figure 27 shows a flow chart that takes as input the MPT and the SROs 
• Points to, and as a resui, of processing wil, add more i,e ms t0 the Z 
■n the missing information ,h.fs mi^g in , he Ip spT ^ ^ 
unnumbered. 

Figure 30e shows the n> and IPX SPTs that would be produced for th. 
network ,n,„„ively shown in Figure 28 and with routers having ,„e 
configuration fUes shown in Figures 29a - 29d Notice that the ,P SPT oniy has 
a connection for the FDD, because on, y a, the FDDI pons are there are 
IP port addresses At a» the seria. ports, IP-unnumbered is used The IPX SPT 
on the other hand, has connections associated with the two seriaj iinks 

In Figure 27, Step (,) sets C to the firs, connection in MPT Step fn 

asks whether this connection has a non-IP subnet lf,h- 
... _ suonet. If the answer is "no" then 

tnis Connection does not need to be processed a„H .h. 
,, . , processed, and the process goes to Sten 

(3) to process the ne* connection in the MPT. If « s ,ep (2,, th e answer is 
yes . ,hen go to Step (5, and determine whether C has ai, the pointers 
associate, with ports tha, have IP-unnumbered address. If ,he answer is "no- 
then continue at step (3) and process the next connection in , he MPT Ifthe ' 
answer is "yes", then add ,o connection IP a new subnet iabeied "IP- ' 
unnumbered." 

Figure 30f shows theMPT tha, wouid be produced after performing th e 
MPT construction aigorithm, shown in Figure 22 , and ,hen appiying the 
algorithm for handling missing i„f ormation due „ ff _ ' 
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Figure 27. Before the IP-unnumbered processing takes place, the MPT would 
look like Figure 3 Of with the exception that connection MPC[1 ] would only 
have a single subnet 9c, and not "IP-unnumbered" in the subnet list; similarly 
MPC[2] would only have a single subnet 8b, and not "IP-unnumbered" in the 

5 subnet list. The IP-unnumbered subnets shown at points (1) and (2) in Figure 
3 Of are added during execution of the "IP unnumbered processing algorithm 
(Figure 27). The reason that "subnet: IP-unnumbered" is added under MPC[1] 
is the presence of the IPX connection between ports R3,S0 and R5,S0 and the 
fact that both of these ports are configured for IP-unnumbered. Similarly, the 

0 reason that "subnet: IP- unnumbered" is added under MPC[s]is the presence of 
the IPX connection between ports R4,S0 and R6,S0 and the fact that both of 
these ports are configured for IP-unnumbered. 

Figure 40 is a flow chart that describes the process for finding 
mismatched bandwidth statements and mismatched delay statements. (Note: 

5 this is a non-routing integrity check; see Figure Id). On each port in a router, a 
bandwidth and delay statement is either explicitly or implicitly configured. 
These are used by both the IGRP and EIGRP routing protocols to compute the 
"cost" of a routing path. The process illustrated by flowchart in Figure 40 
looks for conflicts, where two adjacent router ports are configured with 

0 different bandwidth and/or delay metrics, which may or may not be a problem. 
Because mismatching may be inadvertent and detrimental to the network 
operation, it is valuable integrity check information to present to the user. 

The input of this procedure is the SPT^ and the SRO's that it points 
to. The output is a violation set which is initialized to empty in Step (1 ). In 

5 Step (2), the variable C is set to the first connection in the SPT^. The process 
iterates through all the connections in the SPT^. Step (3), asks whether there 
are two or more pointers in C (recall these are pointers to port addresses) 
associated with ports having bandwidth or delay that are unequal. If the 
answer is "yes", go to Step (4) and add the ports in C with a conflicting 
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whether c,s, he ,as, cordon If it is , , he procedl)re 

back to Step (3) Ifin^ n nw^ . 5 go 

W. Step (3) the answer ,s "no conflict", go to Step (5) and 
process the next connection in the SPT, 

Figured P^desaflowchartdepicdngprocessforperfor^ng 
another type of non-routing integrity check, (Figure 2, which looks for aatic 
outes conned on the rou.er tha, point to routers tha, do no. ex,s, i„ ,„ 
network betnganal^ed. This may or may no. be a probiem. 
-he case tha, ,„e static route, next hop address .„ > 

• -J. ^ „ no, match an existing router On the other hand i, m i 8 „, 
pen, to a router outside *. domain ^ ^ ^ ^ ^ ^ 

*«. The ,„ put , 0 tHs flow cha „ „ , he sa of sr0s spannjng 
The output „ a violation lis. which in Step („ is i„i, ialiled to .. _ 
process ,eps through a„ ,„e routers and a„ .he static routes configured Step 
ST to .he firs, s,a,,c rou.e in tne lis, of routers. Step (3) 1 ^ 
here ,s a router „,,„ an IP port address ^ ^ ^ 

op address To determine this, .he procedure searches .hrough al, the SROs 
object, meamng that this static route ^ ^ ^ ^ ^ ^ . 

•he doma,„ of anaiysis. Step (5, asks whether ST is the ,ast stauc route in ,„ e 
list of routers If the answer is ' w ,h. 

Wst- . ^ • «he process terminates. If the answer is 

o . ST ,sse„o the next suticroute and process repea.s. If tne answer to 
S«*> 3) ,s "yes", then the address in tne s.a.ic rou.e is wi.hi„ «„e se. of routers 
and .he procedure goes to Step (5),o process ,„e nex, s,a,ic route if i, exists ' 

Figure 43 describes another non-routing .able toegrny check (See 
Ftgure d.) This imegrify check is responsible for looking at a., the routers- 
access hsts to find prob,ems wimin an access ,ist. An access lis, is a se, of 



ton 
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to filter, an access-list will be processed starting at its first element. If the 
destination matches this first element, then the router looks at the action 
associated with the element; if it's a "permit", the destination gets through; if 
it's a "deny", the destination is filtered. If the first element does not match, the 
5 router goes on to the next element and looks for a match. If processing gets to 
the end of the access list (and thus there's no match) the destination is filtered. 
The checks that are depicted in Figure 43 look at an access list to see if there 
are two or more elements in the access list where the earlier one is more 
general than the later one. If that is the case, the latter one will never be 

10 reached. This relation is called a "subsumption relation". The high severity 
error occurs when the two access elements in the subsumption relation have 
different actions: one says "permit" and the other says "deny". The less severe 
integrity check occurs when the access list elements in the subsumption relation 
refer to the same action. In this latter case, it's an issue of efficiency, in the 

1 5 first case, it's probably a problem, where the user didn't realize that processing 
would not reach this more specific entry later in the list. 

Figure 43 illustrates how the process finds subsumption problems in the 
access lists of the routers. The input to this flow chart is the list of SROs and 
the output is a violation list which has the access list element pairs that are in 

20 violation. Step 1 of Figure 43 sets the violation list to "empty". Step (2) sets 
R to the first SRO, that is, to the first router in the list of routers. Step (3) asks 
whether R has one or more access lists. If the answer is "no", then there is no 
need to process this router and the process moves to Step (4) which asks 
whether the last router has been reached. If so, the process terminates. If not, 

25 Step (5) is reached which sets R to the next SRO and then continues at 

Step (3). If in Step (3), router (R) has an access list, then set a variable Acc to 
the first access list in R at Step (6). 

(A router can have one or many access lists.) Step (7) asks whether the access 
list has more than one element. If it only has one element, then there's no 
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processmg to do because the algortthm „ lookjng for ^ 

*eme„,s. So if ,he answer is .. no , _ (o S(ep ^ o 

.s,he,ast access Hs, in If.hea nsW e ris .. y e s », togotoStep(4)aiid 
process „e nex, r ou,e, If the answer is ..„„,, , hen ^ ^ 

S ep (7) ,s yes , tha, , s , ^ ljs , poimed „ by ^ ^ 

e ement, m Step (,0) se, AcEL , which wi|| be , ^ ^ ^ 

* ement, ,o the second elemen, in Acc. S.ep ,„) asks whetner [here , 

^ T~ AK ACEL ^ iS to ° r — *-a, 

than AcEL If thic i s — ^ ^ ^- , s 

"■-•S"»«^,ihenconmc,s have been located Goto 
S..P (.2) where these conflicts are placed in the vioiation hst. ,f ,„i s is no. the 

uZ ^ ^ " <13> - " WhMher ACC - 

If «he las, elemen, in Acc has been reached, ten moV e on t0 Slep (g) which 

processes th next access list in Rou , er R ^ ^ ^ 

Step (,3,, then St ep (,4, se,s AcEL to the next elemen, in the access ,i sl , and 

the process continues processing this access-lis, element 

Each router typically has a routing table for each Level 3 protocol A 
rou.,„g table is response for determining the "next hop" a packet of data 

7 3,0,18 ' he ™* from * «— i«s destination The "next hop- 
refers lo the next adjacent router along the "oath" thr„.„j, i 

, , , b pat " ""ough the network that the 

C f 7^ enroUtt ' 0 ~onA rou n, gt , Ieco ^ 
of a se, of elements, each having a destination to match again, and a "next 
hop specification When a packet enters a route, the router ,ooks in its 
routmg table to find a matching Cement. ,f . raa , ch is found , hen 
. ,-,e next hop (N o,e: there could be more than one next hop, mea^ 
•ha, there are m u„ip,e choices). „ is possible tha, for a part.cu.ar destination 
no ™, e 1S „„, in the routing ^ ^ ^ ^ ^ ^ ^ 

» «*d a ga,eway of ,as, resort which might or might no, be se, ,f i, „ not 
s=., ,hen packe, being ma,ched is dropped by ,he rou,e, ,f a g a,eway of ,as, 
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resort is set, it will be handled like any other routing table element, which the 
router will use as a defined "next hop". 

Figure 45 shows, in attribute form, a Routing Table Object. For each 
Level 3 protocol, each router will have a Routing Table Object. In the first 
5 field of the Routing Table Object is the Protocol attribute, which is set to IP, 
IPX, APPLET ALK, etc. In the second field is a pointer which is either empty 
or references a gateway of last resort (which is a Routing Table Element 
object described below). The last high-level attribute, which contains the bulk 
of this object, is a set of routing table elements. Each one of these mentions a 

10 destination and if this destination matches, where to go next. 

In Figure 45, reference numeral (1) refers to routing table element 
EL[1], which includes a destination. The different protocols have different 
ways of describing the destination. For IP, a destination is given by an address 
and a mask. For example, consider a destination with an address being 

15 10.10.0.0 and a mask being 255.255.0.0. In this context 255 in the mask 
means pay attention to the corresponding octet, 0 means ignore the 
corresponding octet. So for example, 10.10.0.0 255.255.0.0 would match 
anything that starts with 10. 10 and any other setting of the last two octets. In 
general mask Octets can be any number from 0 to 255 and "matching" is 

20 decided by applying the mask using Bit-wise AND. 

The second part of a routing table is an attribute "Cost Paths", which 
can have one or more elements. Each Cost Path element (see reference 
numeral (2) in Figure 45) contains five attributes. First, is Protocol indicating 
the routing protocol that caused the element to be put in the routing table. 

25 This attribute can have a number of settings. A routing table element could be 
there because it is a directly connected interface; it could be there because there 
was a static route; or it could be there because it was learned by a dynamic 
routing protocol such as RIP, IGRP or OSPF, etc. The second field, 
Cost/Administrative distance, is an attribute that is used in the case of two or 
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more rou t es being available. When .here are two routes, the router trie, ,„ 
deterge the best route. The Cost/Admin. distance vaive is a metnc tha, is 
used for comparison ,o find the best route. The third field. Interface teils 
whtch portWace to send a matching packet ou, of The Next Hop pointer 
w,U be non-empty if the protoco, was .earned either from a static route or a 
dynanuc proton, and this te„s „ha, „e„ router to send the packet to Lastly 
the field. Interface Conn, refers to a connection in the SPT of the 

corresponding protocol that is attached to the interface idemified in the third 

field. 

Recall that /*/^Qt _ _ . i 

- •-^■~M-p 0 „„ may „ave one or more elements. It is possible to 
have a number of eoual cost-paths in which case cost-paths win have two or 
more dements showing the different ways the router can route the packet 
The routing table data structures can be obtained in two basic ways 
these structures can be obtained by reading the routing tables from the live ' 
routers in the network (the process shown in Fig le) or by con)pulinf , ^ 
through sunulation, using the integrated SPT/SRO object model as input ( the 
process shown in Fig ,f, If IP routing tables are being computed then the IP 
SPT ,s used; if IPX routing tables are being computed then the IPX SPT is 
used, etc. 

An important benefit of computing routing tables, rather than observing 
them, „ that a simulation using computed routing tables can indicate what 
happens to the routers under hypothetical failure scenarios enabling a pro- 
active failure analysis. 

The routing tables being used and computed by the invention refer ,o 
steady-state" routing tables. The steady-state routing tables are the routing 
tables that are produced once the routing process settles; in a live network the 
routing tables can converge to a new state when network devices Qr ^ 
pom change in status (i.e., whetiter they are operational or failed); routing 
Ubles can also converge to a new s*.e when tire configuration of the routers or 
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other network devices are changed, new devices are added, or existing ones 
removed. By saying that the invention is computing steady-state routing tables, 
we mean to imply that the invention is not computing information about the 
convergence process, such as the settling time or the number of messages 
exchanged during convergence. 

Focusing on steady-state, rather than also the transient states, allows 
novel efficient techniques to be applied in this invention because the invention 
can "cut to the chase"; this is in contrast to the live routers running, for 
example, the periodic distance vector protocols, such as RIP and IGRP, which 
must do a lot more cycling before obtaining a steady-state. 

The invention's routing table simulation technique draws on the 
published specification of the standardized routing algorithms, such as RIP and 
OSPF, and draws on the vendors' public specification of their own proprietary 
routing protocols, such as Cisco's IGRP and EIGRP routing protocols, as well 
as the vendors embellishments and slight modifications to the standardized 
routing protocols. 

We separate the part of the invention that models the published 
algorithms from the rest of the structure, which constitutes the invention's 
novel contribution, by defining the functions below, which capture the 
published algorithm's behavior. These functions below are used for all of the 
routing protocols being treated. 

SEND(RT_EL,RP <Ro,Po>) is a function computable from Ro's SRO 
that returns either null if router Ro cannot generate from routing table element 
RTEL an update using routing protocol RP and send it out interface Po; 
otherwise this function returns the routing table element that router Ro would 
send when advertising route RTJE1 out interface Po using protocol RP. If 
SEND(RT_EL,RP,<Ro,Po>) is non-null, then its destination is either the same 
as RTJEL's destination or more general than RTJEL's destination (in which 
case we say that it refers to a summarized route). Also, if the value of 
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SEND(RT_EL,RP,<Ro,Po>) is „o„-„„„, ,„ e „ the protocol ^ 

*. v,ue win be RP. If the elenalt RT_EL Has its protocol atlribute ~ 

or .o Dtrcc, Connect (nKMIng „. i( reftre , o a direc% 

*» we say , ha, SEND(RT_EL,RP,<Ro,Po>) refers lD „ atively * 

- """""""^ we ^ «■* SEND(RT_H,RP, < R„,p 0>) refm 
rcd.unbut.on of RT_EL into protocol RP 

funct, on SEN D( RT_EL,RP,< Ro , Po > ) 

~*«* enabled by , he configuration of protoco, RP f or rouler Ro 

WW, - captured by the (routing) protocol objec( jD Ro , s SRO ^ protocoi ' 

a..n^,c *, ,„ RP (see Fig, 2 for ,he placemen, of , his object in the SRO and a 
Pan* v,ew of a rout.ng protocol object). There are many roul i ng protoco| 
conf,„ commands ,ha, i mp ac, what routes _ ^ ^ 
route f„,en can be configured for a routing protoco,, which consist of 
references to access-hsts tha, indicate which destinations a routing protocol M „ 

~ « -—mp.e is passive interfaces; if protoco/RP has a passive 
■nterfac, „„ ,„, e rface (i ,., port) Po, then this protoco, win no, send any 

updates out of port Po. 

SRO ,„ R£CE,VE<RT - EL RP - <R '>. P -) " = Action computab.e 

SRO tha, returns „ u „ if either router Ro js M ^ ^ ^ ^ ^ 

»er or otherw.se block element RT_EL in an update from routing protoco, 
RP com,„ B ,„ interface Po; otherwise , he mncti[ , n returns ^ ^ 
*— that router Ro win consider putting ir , lls routjng (a|>le ^ 
an update from RP containing element RT_EL 

Suppose that REC EI VE(RtW<Ro,Po>) is non-nul, and return 

S - ":n RT - a - rt - el2 - - *. viewing ways: 0 

" * (W ' h RT - EL2 ' S *■ » being .arger), ii) RT bLs 

nterface attribute wil, be se, to the name associated with Po. iii) RT EL^ 
In.erface.Conn attribute win be se, to the SPT connection attached « P 0 and 
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iv) Next_hop_pointer will be set to the pointer on the SPT connection 
associating with the router sending the update (so being more formal would 
require RECEIVE to take as another argument the sending router) 

The function RECEIVE(RT_EL,RP,<Ro,Po>) embodies the routing 
5 update "receiving" behavior enabled by the configuration of protocol RP on 
router Ro (if RP happens to be enabled on Ro). For example, a configuration 
option that can block the reception of incoming updates is the setting of an 
input route filter. 

COMPARE(CostInfol, CostInfo2,RP,Ro) - is a function computable 

10 from Ro f s SRO that returns one of the three states: Greater_than, Equal_to, or 
Less_than. If cost/admin, distance of Costlnfol is less than that of CostInfo2, 
Less_than is returned; if the cost/admin, distance of Costlnfol is greater than 
that of CostInfo2, Greaterthan is returned; otherwise the two cost/admin, 
distances are equal and Equal is returned. 

1 5 (Note: For simplicity here we are not presenting the more general form 

of SEND and RECEIVE used in the invention that is applicable in cases where 
the router sending the update and the one directly receiving it are not directly 
connected, such as can be the case for BGP (which can use remote neighbors). 
The invention generalizes SEND and RECEIVE so that, rather than just taking 

20 a port as an input, it can also take an argument that designates the router that is 
receiving or sending the update) 

Figure 44 depicts the process the invention uses to compute the steady- 
state routing tables for protocol P (e.g., IP, IPX, AppleTalk) given a SPT for 
protocol P, the SROs it points to, and the operational status of each router, 

25 each of its ports, and each of the connections in the SPT. A routing table is 

computed for each router in the set of SROs given as input. The output routing 
tables are the steady state routing tables that would be produced by running all 
the routing protocols that are specified in each router's SRO. The invention's 
algorithm is applicable when there are multiple routing protocols running on 
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one or more routers. It also handles redistribution between r^' 

from RIP into IGRP is enahi*»n i , redistribution 
output routing ,ab,e Cement te can tave . ^ ™ " ~« » 

. , ""or message passing scheme based on 

mcrementaj upda.es, similar as to what „ used by E , GRp ... " 

algonftmstha, use difference meehods during th e,>co„ve 

- Periodic dis,ance vector (fa, mi 1GKP) ' T *"* 

v r and 1CrRP ) Jink state (OSPF 1^ K 

mtt 1rn>n „ . Just a 32 blt destination used bv RIP 

and ZGRP are for uniform*, jn inlptememation ^ 
™e advantage of treating „, ^ type „, 8 P 

-erne is that , faciiitates a genera, mechanism for 4^1,7^ 
■ncorporating a new routing alttorithmin, ... • K 

In Step O , of ,h. " mVemi ° n mUC " MSier 10 ""fa 

44) J„ ™''"«<ab,e simulation algorithm" (shown in Fig 

44), each routing table (for protocol PI for M >. 8 

Direct Connect (see Fig 45 ooim 21 »i. u " otoco1 "t «> 

(see point 5 on Figure 2) ttatT , "** r<>U,e ""^ « R ° 

on rigure 2) that is not associated with a faileH n« rt • 
routing table with Protocol set to Static , ft , ' P ° rt ' 15 PUt In Ro ' s 
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routes that mention a router interface; although the invention treats both types, 
for simplicity in the Patent we just discuss the statics to a next hop address). 

In Step (3) the static and directly connected routes are advertised. For 
each operational router Ro, each of its routing protocols RP will tiy to 
5 advertise update messages out its operational ports for the static and directly 
connected routes put in its routing table (in Step (2). The function SEND is 
used in this step to determine which routes are permitted to be advertised out 
of what ports (as dictated by each router's configuration as captured by its SRO 
(from which SEND is computable)). 

10 An update message sent from Router Ro out port Po in Step (3) is 

directed (in the simulation) to the SPT connection that is attached to (i.e., 
points to) router Ro's port Po. In Step (4), each failed connection drops any 
message it receives, while each operational connection passes the message to 
each of the other Router/ports attached to the connection. 

1 5 Step (5) refers to the process where for each update that an operational 

router receives, it determines for each routing table element in the update 
whether it should be processed or discarded. A failed router that receives an 
update or a router that receives an update through a failed port simply drops 
the update. The RECEIVE function is used in Step (5) to determine if a router 

20 is configured to receive each routing table element in an update message. In 
Step (5), the router is also computing the new cost/admin, distance to be used 
for a received element, which is typically higher than the one it received (this 
"new cost" computation is embodied in the RECEIVE function); in Step (5) the 
router also discards any element where its new cost/admin, distance is greater 

25 than an routing table element already in the routing table with matching 
destination. The function COMPARE is used in this step to make this 
cost/admin, distance comparison. The output of Step (5) is a set of 
UPD TO PROC sets for each router, capturing the update elements that need 
further processing. 
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In Step (6), for each router Ro with one or more UPD JTO_PROC sets 
« win add each member from each one of these sets and put itL touting ' 
table, replacng any route previously in its routing table having higher 
cost/admin, distance. If the new route being added matches a route already in 
the table with equal cost/admin, distance, then the resulting table wi.l have 

( ;r; OS : rOUteS> - C ° nditi0n memi ° ned ^ ** G> * «* an 

exact match ; by th.s we mean that two routes have exact same destinations 

cost/admm distances and in addition match on the other attributes such as 
ln t erfa C e(seeF lg ure4 5 point 1) (Note: for simplify here we preS ent an 
a-gonth... that allows muitipie routes that have equal cost/admin, distance this 
■s eas,ly generalized to handle multiple routes where the costs may differ a 
poss.bmty for example, when using Cisco's IGRP variance command) 

In Step (7) each UPD_TO_PROC set is examined to look for and 
remove any routing table element that when put in is an "equal cost/admin 
Stance" route, that is a route that matched an existing destination and has 
equal cost/admm. distance. The reason for removing these elements is because 
m the next step these "incremental changes" will be sent out and it is not 
necessary to send out an incremental change corresponding to a new. but equal 
cost/admin, distance route. 

In Step (8), the "incremental updates", which are in the UP_TO_PROC 
sets will be advertised both through the native protocol associated with'each 
element in a UPD_TO_PROC set and by redistribution. The SEND function is 
used m this step to determine which advertisements and redistributions are 
permitted by the configuration. Consider an element EL in a UPD TO PROC 
set for router Ro. For the protocol RP associated with EL 
SEND(EL,RP )R o,Po) will be non-null only if the router Ro is configured to 
nat.vely send EL (using protoco. RP) out Po. For a routing protocol RP X 
afferent from El's protocol, SEND(EL,RP_X, Ro ,Po) will be non-null on"l y if 
the router Ro is configured to redistribute from EL's protocol to RP X and 
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send it out port Po. Like Step (3), Step (8) will only send updates out 
operational ports. 

Step (9) checks whether any updates are sent in Step (8); if not then the 
process terminates; otherwise the algorithm loops back to Step (4) where the 
5 new updates are processed. 

Figures 44a and 44b show grafts onto the algorithm in Fig 44 for 
additional processing that efficiently handles loop conditions; as an update is 
passed from router to router, the update is tagged to produce the list of routers 
that the update has visited. The tagging is done in Step (A) shown in figure 

1 0 44a, which is inserted between Fig 44's Steps (3) and (4). Before a router sends 
out an incremental update, it checks if the update is in a loop; if it is, then it is 
dropped. Fig 44b shows this process as Step (B), which is inserted between Fig 
44's Step (7) and Step (8). The reason for "cutting off loops" at this point, 
rather than earlier, before Step (5) when an update first reaches the router, is 

15 we want to leave the routing tables in a "loop state" so that it can be picked up 
by the "Routing Loop" Integrity Check, shown in Figure 73. 

A novel aspect of the invention's steady-state routing table computation 
is that it identifies routing loops. It is possible to configure the live routers so 
that they produce i) persistent, ii) periodic, or iii) transient routing loops for 

20 different destinations. Routing loops that result after the procedure in Figure 
44 terminates can be of any of these three types. By having an integrity check 
point presence of routing loops, the user can then look at the live routers to 
judge the severity of the problem. Clearly, persistent routing loops are the 
most severe and the transient loops are least severe. The severity of periodic 

25 routing loops depends on the frequency that the routing table destination is in 
"loop state" versus a non-loop state and whether the non-loop state results in 
correct routing or a no route condition. Many times, for periodic routes, the 
user may not be aware because he or she may poll the table while in a good 
state. Thus knowing about loops, which can be periodic, is valuable diagnostic 
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information. (Note: to be formally strict here, in the real routers there may not 
be a "steady-state" condition for some routing destines, such as those 
-nvolved in a periodic routing loop; for this particular case, our algorithm 
presents one of the cases, in the steady-state routing tables.) 

Another novel aspect of the invention stems form the fact that in some 
cases, the simulation "fleshes out the non-determinism" found in the live 
routers. For example, the actual routers can be configured to keep only up to 
two (equal cost paths) for each destination. If there happens to be more than 
two equal routes, two of them will be arbitrarily chosen. In contrast the 
mvention can find a„ the equal cost paths to a destination D and show them all 
reporting "two out of the following X paths will be chosen to destination D« ' 

Another contrast between the invention and live routers is that the 
.nvennon exploits the fact that in its simulation model all the routers' models 
are ,n the same memory space, as opposed to a live network, where each router 
has its own memory space. For example, Step (9) in Figure 44 is a question 
that could be asked only if the routers where in the same memory space It is a 
question that looks at global convergence. 

Recall that the processes in accordance with the invention have the 
ability to either import routing tables from the live routers or to calculate the 
routmg tables based on information in the SROs and SPT's. In either case 
once the routing table objects are populated, there are a number of integrity 
checks that can be applied. To see where in the overall process of the 
mvention these routing table integrity checks are applied, refer to Figure Ig 

Before describing how the particular integrity checks operate there are 
some preliminary concepts that need to be discussed. The routing tables as we 
alluded to, are used by the routers when they receive a packet. When a host 
wants to forward a packet to another destination it will send it to its 
neighboring routers and that router, if it has a routing table element, will send 
to a next hop router en route to a final destination. So in this process the 
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routers will send packets of data from hop to hop until they reach the 
destination. So in a sense, given a set of routing tables they implicitly define 
paths through the network going from a source to a destination A concept 
that we'll define here is the notion as to whether given a source address and a 
5 destination address there is a path that exists throughout the network; and if 
there is, what path will be taken; and in a case where multiple paths can be 
taken what are these multiple paths. 

Figure 47 shows an example network that shall be used for explanation. 
In this example, there are five routers, Rl through R5. Rl and R2 are 

10 connected through an Ethernet (Conn[l]). Rl is connected to R2 through a 
serial link (Conn[2]). Router R2 is connected to Router R4 through a serial 
link Conn[3]. R3 and R4 are connected through an Ethernet (Conn[4]). R5 is 
isolated. It's just connected to an Ethernet (Conn[5]). Source Addresses and 
Destination Addresses, SA and DAI are respectively source and destination 

15 addresses on Conn[l], DA2 is a destination address on Conn[4] and DA3 is a 
destination address on Conn[5]. (Note: When we sav source and destination 
address that's an arbitrary distinction. We say source address because it's used 
as a source in our example and destination address because it's used as a 
destination in our example. 

20 Continuing in Figure 47, the output for the analysis, which given a 

source address and destination address shall be called herein a "Completed Path 
Set." A Completed Path Set (CPS) will be empty if there is no path from SA 
to DA (where SA refers to the source address and DA refers to the destination 
address). If CPS has one element that means that there's one path from SA to 

25 DA and if it has more than one element there's multiple paths between the 

source and destination. For the example network, suppose we are considering 
a CPS (a Completed Path Set,) for a path from source address SA to DA2. In 
this case, there will be two paths, one of them that starts at SA and goes to 
Conn[l], Rl, Conn[2], R3, Conn[4] and then gets to the destination DA2. 



MSDOC1D: <WO 97492 14A1J_> 



WO 97/4SE14 



PCT/US96/10873 



-82- 



The second path starts a. SA , gees «o Connf,], R2, Co^S], R4, Conn^ and 
then ,o DA2. If on the other hand, „e are interested in a CPS where ,he 
source destination is SA and the destination address is DA,, (this is a case 
where the source and destination are on the same subnet,, there would be one 
pa«h;fromSA,oCo„„[,],oDAl. An example where there is no path isifa 
pac.ee, is ,„ go from SA to DA3. In this case, CPS would be represented as an 
empty set. 

Figures 48a-48c depict a flow char, tha, the invention follows to 
produce a CPS. a completed path set, given a source address and a destination 
address. A novel aspect of this procedure is that i, idemifies multiple paths 
between source and desunation and is performed off-line; this is in contrast for 
example, with Cisco System's Path Tool, which is an on-line tool that o nly ' 
■dentines the current path, no, al, ,he possible one, An advantage of knowing 
all the paths is that the curren, one might be working while another possible 
path, which can be chosen a, a, ater time, might have problems. Thebestway 
.o present this is a walkthrough of a particular example Refer now our 
attention on Figure 51, which is a generated block diagram of a network very 

"* '° °" e " ^ A1 - but «*» - -M- «"k. 4e link labeled ConnlS] 
betweenR, and R4. 

Th ~ for including this link is to show what happens in fte case of 
routtng table element with multiple paths. In this example, a CPS will be 
produced in which the source address is SA and the destination address is DA 
The mput to the process of Figure 48 is the SPT for the protocol under 

consideration, so in this case it«i nn qpt t?- m . 

° aSe ' lts an SP V F, gure 52 shows the SPIV, that 
^ corresponds to Figure 5 1 . 

Figure 53 shows the IP routing table for router R, . The element 
labeled EL[1], has destination 10.10.0.0 255.255.0.0. It has one cost-path 
wh.cn corresponds to the fact that it is directly connected. Routing table ' 
element EL[2] corresponds to destination 199.28.77.0 255.255.255 0 and this 
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again is directly connected and corresponds to interface SO. Element EL[3], 
like elements EL[2] and element EL[1] corresponds to a directly connected 
interface. Element EL[4] is the only element out of the four which corresponds 
to a route that was dynamically learned. This corresponds to destination 
20.20.0.0 255.255.0.0. There are two cost-paths in the example, showing that 
there are two different ways to leave the router if a packet matches this 
element. The Cost Path element on the left indicates it was learned by RIP; it 
has a cost/administrative distance of 1/120. It's interface is SO. The next hop 
pointer is to router R3, SO and its interface connection is Conn[2]; the second 
cost-path object is also learned via RIP and has the same administrative 
distance as the first cost-path. This object specifies output interface SI, rather 
than SO. Its next hop pointer is R4,S1 and its interface connection is Conn[5]. 

Figure 54 shows an IP routing table object for R2. Figure 55 shows an 
IP routing table object for R3 and 55a shows an IP routing table for router R4. 

The flow chart in Figures 48a-48c shall be described in the context of 
the example by going through the walkthrough in conjunction with 
Figures 56a-56f. Starting in Figure 56a refer to reference numeral (1), which 
indicates that in Step (1) of the flowchart in Figure 46a the output produced is 
the CPS, is set to "empty". Step (2) asks whether there is a connection in the 
SPTn, (Note: in this example, P is IP because the example looks at a 
destination address and source which are both IP). The answer in this case 
"yes". If this was not the case, that meant that the source and destination were 
on subnets that the object model did not have and consequently the analysis 
could not proceed. If the answer is "yes", for convenience, at Step 3 the 
variable SC is set to the connection in the SPT which matches SA's subnet. So 
for this example SC is set to Connfl] because SA is directly connected to the 
Ethernet labeled Conn[l]. Step (4) sets DC (which is a variable referring to the 
destination's Conn) to the subnet matching DA; in this case it is Conn[4] 
because DA is directly connected to Conn[4]. Step (5) asks whether SC equals 
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DC. In other words, are the source and destination on the same subnet? If that 
» the case, go to Step (6) and return a CPS with one element where the path is 
from SA, to the shared connection, to DA, a very simple path. If the answer is 
'no", wh,ch ,s the case in this example, go to Step (7) (labeled on Figure 48b) 
and mitialize a variable called APS (for "active path set") to the path that is 
bemg constructed. In this case, there are two paths in progress. The first one 
starts at SA, goes to Conn[l] and to router Rl, and the second one goes from 
SA to Conn[, ] to router R2. In general, at Step (7), the procedure puts in as 
many elements as there are routers connected to the source's subnet. 

In Figure 56a, we show the progress of APS, which are paths that are 
incrementally building. So in this example, we can see that we have two paths 
shown by the dotted lines that both start at SA and one that ends at Rl and the 
other that ends at R2. As the process proceeds, it will be picking one of the 
dements in this set to extend by a hop and then puts it back in APS unless it 
gets to ,ts destination the router that drops the packet or is involved in a 
routing loop. 

Now refer to Figure 56b, and more specifically to the reference therein 
to Step (8) (from the flowchart in Fig. 46b), which asks whether there are any 
elements (active paths) in APS. If it's "empty", the process terminates If it is 
not empty, then proceed to Step (9). In this case, since the APS has two 
elements, proceed to Step (9). Step (9) sets the variable CP (for "current 
path") to one of the elements in APS and removes this element from APS In 
the example, CP is set to the first path, which goes from SA to Connfl] to 
router Rl. I„ Step (10) for convenience we are letting the variable, CR (for 
"current router"), refer to the last router in the path CP. In this case the 
current router is Rl since there is only one router in the path. In Step (1 1) we 
ask, "does CR appear in the path more than once." This is a check to see if we 
are in a routing loop and to protect this procedure from being in an infinite 
loop. If CP refers to a loop, we add CP to the set of routing loop paths and 
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proceed by going back to Step (8) to see if there are any more paths to process 
in APS. If there is no loop, we go to Step (12) where we set a variable called 
CPO, standing for the Cost Path Objects, to the set of Cost Path objects 
associated with a routing table element that matches the destination address in 
the current router's routing table for the applicable protocol; IP in this case). If 
there are no elements matching DA and no gateway of last resort, CPO is set to 
null 

The bottom of Figure 56b shows the cost paths that is set to CPO in 
Step < 1 2 ) These are the two cost paths that are circled, the ones that are 
under element ELf4]. The details of how Step (12) is executed are depicted in 
the flowchart tn Figure 50. In Figure 50, the input is a routing table (the 
routing tabic for the router and protocol under consideration - Router Rl and 
protocol IP in this example) and DA which refers to the destination address. In 
our example, the destination address is 20.20. 1.9. The output is the CPO, in 
other words a set of cost path objects that match the element DA. If there is 
no match, CPO will be empty. 

Let's walk through this flowchart. In Step (1) it asks are there any 
elements in the routing table that belong to the same major net as DA. For 
example, the major net that is associated with 20.20.0.0 is 20.0.0.0. (It's a 
Class A network address as opposed to being a Class B or Class C address). 
See, Martin, James, "Internet Address Formats", Local Area Networks 
Architectures and Implementations, pp. 439-440, PTR Prentice Hall, 1994. In 
Step (3) of Figure 50, we set EL to the element in the routing table belonging 
to the destination's major net having the most specific mask. The most specific 
mask is the one with the most 255s on the left. In this case, there is only one 
element in the routing table shown in Figure 56b belonging to net 20.0.0.0 and 
that is element EL [4]. Proceeding to Step (4) we ask, "does this element 
match the destination address?" We look at the destination in element EL[4] 
and we see the destination is 20.20.0.0 with mask 255.255.0.0. That means we 
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are looking for any destination that starts 20.20 and don't care about the last 
two octets. In our example this matches. So the answer at Step (4) is « yes " 
and the procedure exits, returning this element's cost path set which are the 
two arcled cost paths in Figure 56b as output. If it didn't match, we would go 
to Step (5) and see if there are any other elements belonging to DA's major 
network which have a more general mask and then go back to Step (4) and try 
to apply the match. If the answer to Step (5) is "no" then we go to Step (2) 
which asks the question, "is there a gateway of last resort?" If it is we return 
the CPO associated with it; if not, we return saying the CPO is empty Also 
we should note that in Step (,) if there are no matching elements in the routing 
table that belong to the same major net as DA, we go to Step (2) and look for 
gateway of last resort and return the CPO associated with it, if it is found 
otherwise an empty CPO is returned. So in general, this procedure iterating 
lookmg for the most specific match; if one is found, its CPO is returned. If we 
don't find any matches then we return the gateway of last resort's CPO if it 



exists. 



Let's continue the walkthrough at Figure 56c. To set the context we 
had reached Step (12) as shown in 56b, which identified the CPO as being the 
arcled items; in other words, the items under element EL[4] in Figure 56b In 
Step (13), we ask the question, "is the CPO empty?" In this case, since there 
are two elements, the answer is "no" and we go on to Step (14). If it were the 
case that the CPO were "empty", meaning that there are no routes in the 
current router that match the destination address, then we are in a sense 
discarding this active path and going back to Step (8) t0 see if there are any 
more active paths to process. In our case, as we said, there was a match so we 
go on to Step (14). In Step (14) and (15) we take one of the elements of the 
CPO, remove it, and set EL to the CPO we're processing. In this case, L is set 
to the CPO as depicted in Figure 56c, one CPO who's interface is set to SO 
We next go to Step (16) which asks, "does the destination connection (DC) 
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match the EL's connection?" In other words, "are we pointed to the interface 
attached to the media on which the destination is connected?"; in this case, the 
answer is "no" because the destination connection is Conn[4], but the 
connection associated with EL is Conn[2]. So the answer at Step (16) is "No" 
and we go on to Step (17). In (17), the current path is extended with the 
element's Conn[2] (EL's interface Conn) and the next hop router R3 and put 
back in the set of active paths APS. The diagram in Fig. 56a pictorially shows 
the paths being developed that currently are in APS. 

The walkthrough continues at Figure 56d; after processing Step (17), 
we go back to Step (13) and see if there is (another) cost path object to 
process. In our example, since there was two paths out of the router 
associated with the matching routing table element, there is another cost path 
object to process. In Figure 56d, in the items marked (14) (1 5) we see that 
CPO is set to the cost path object who with interface is set to S 1 . We then go 
to (16) and ask the question, "does the connection associated with CPO, which 
in this case is Conn[5], match the destination connection Conn[4]. The answer 
is "No"; we haven't gotten to the destination connection. So we go back to 
Step (17) and add a new path to the APS. In this case it is the path that starts 
from SA to Conn[l] to Rl and this time rather than going out SO, we go out 
SI to Conn[5] to Router R4. The diagram in 56d depicts the three paths under 
construction that are on the APS after we execute Step (17). 

The walkthrough continues at Figure 56e. After processing Step (17) 
we go back to Step (13) and ask "is the CPO empty?" This time the answer is 
"yes, it is empty", so then we go to Steps 8 and 9 which refer to picking one 
element from the APS, if it is not empty, and seeing if we could add another 
hop to it in trying to reach the destination. So after going to Step (8) and 
getting the answer that APS is not empty, we go to Step (9) where we set CP 
to one of the elements in the APS. In this case we set it to the path labeled 
Path A in diagram 56d. Step 10 mentioned in Figure 56e refers to setting CR 
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to the last router in the current path, R4. We then go to Step (12), which looks 
through R4's IP routing table for a match to destination address DA In this 
case, a matching element is found with a CPO that is depicted right after Steps 
(N>and(15)inFigure56e. This CPO is a directly connected CPO which 
means ,ha, the matching destination, which is Subnet 20.20.0.0 is directly 
connected CPO's interface is set to E0, (Ethernet 0), since it is directly 
connected ,t does not have a next-hop pointer and associated connections 
C onn(4J We then go to (16) which asks the questions, "does the destination's 
connects. wh,ch ,s Conn[4], match the one on the CPO that we are 
proce^ The answer here is "yes". So, after Step (16) we go to Step (18) 
wh,ch ,s the first „me in this example, we have added to the CPS; thus, we 
have reached the destination; the path that gets added to the CPS is one that 
goes from SA ,o Conn[l] to Router Rl to Conn[5] to Router R4, out Conn[4] 
to the destination address. 

After Step (18) processing goes to Step (13), which returns "yes" since 
there are no more cost path objects to process; consequently, the algorithm 
goes to Step (8, At Step (8), the APS has the two paths shown in Figure 56f. 
Tms processang of elements in the APS repeats itself; the end result will be that 
the CPS has 3 dements which are shown in the computer form at the bottom of 
F.gure 56f and shown in the diagram in the middle of Figure 56f, the paths are 
from SA to Conn[,] to Rl to Conn[2] to R3 to Conn[4] to DA; f rom SA to 
Conn[ . ] to Rl to Conn[5] to R4 to Conn[4J to DA, and from SA to Conn[l] 
to R2 to Conn[3 j to R4 to Conn[4] to DA. 

One of the complications that we have to take into account in 
construing the CPS is that the routers might have both input and output 
access hsts These, as we described before, are filters that can block traffic 
commg into the router (an input port filter) or going out of the router (an 
output port filter). If the procedure runs into an access list that blocks the path 
being constructed, then it will not put it into CPS. 



